行の 90% でインデックス付きのINT
列が 0 になる MySQL テーブルがあります。これらの行をNULL
0 の代わりに使用するように変更すると、インデックスから除外され、インデックスが約 90% 小さくなりますか?
5 に答える
NULL
s にも インデックスを付けているようです。
MySQL はインデックスの作成中に WRITES のためにテーブルをロックするため、これを実行するときは注意してください。列が空 (すべて NULL) の場合でも、大きなテーブルではインデックスの構築に時間がかかることがあります。
参照。
列をnullに許可すると、列のストレージ要件に1バイトが追加されます。これにより、インデックスサイズが大きくなりますが、これはおそらく適切ではありません。つまり、クエリの多くが「ISNULL」または「NOTNULL」を使用するように変更された場合、値の比較を行うよりも全体的に高速になる可能性があります。
私の腸は私にヌルではないと言うでしょう、しかし一つの答えがあります:テスト!
いいえ、引き続きそれらが含まれますが、どちらの場合でも結果がどうなるかについてあまり多くの仮定をしないでください。多くは他の値の範囲に依存します(「カーディナリティ」のグーグル)。
MSSQLには、このタイプの状況に対応する「フィルター処理されたインデックス」と呼ばれる新しいインデックスタイプがあります(つまり、フィルターに基づいてインデックスにレコードが含まれます)。dBASEタイプのシステムにも同様の機能があり、非常に便利でした。
各インデックスにはカーディナリティがあります。これは、インデックス付けされた個別の値の数を意味します。私の知る限り、インデックスが多くの行で同じ値を繰り返すと言うのは合理的な考えではありませんが、インデックスは繰り返される値を多くの行のクラスター化インデックス (このフィールドに null 値を持つ行) にのみアドレス指定し、クラスター化インデックスの参照 ID を保持します意味 : NULL 値のインデックス フィールドを持つ各行は、PK と同じサイズを無駄にします (このため、複合 PK がある場合、専門家は適切な PK サイズを持つことをお勧めします)。