MySQLデータベースがNULLを可能な限り避ける理由

MySQL の多くのテーブルには、NULL が列のデフォルト属性であるため、アプリケーションが NULL を保存する必要がない場合でも、NULL (空の値) になる可能性がある列が含まれています。しかし、MySQL のパフォーマンス最適化に関する書籍やブログでは、データ列で NULL 値を使用しないようにし、本当に NULL 値を格納する必要がない限り、0、-1、またはその他の特別な識別子を使用して NULL 値を置き換えるようにするという意見をよく見かけますが、なぜでしょうか。交換した場合の利点は何ですか?同時に何が問題なのでしょうか?次に、次の点を見てください。

(1) クエリに NULL になる可能性のある列が含まれている場合、NULL になる可能性のある列によってインデックス、インデックス統計、および値の比較が複雑になるため、MySQL の最適化がより困難になります。

（２）NULLを含む複合インデックスは無効です。

（3）NULLになる可能性のある列は、より多くのストレージスペースを使用し、MySQLで特別な処理も必要になります。

（4）NULL可能列にインデックスを作成すると、各インデックスレコードに追加のバイトが必要になり、固定サイズのインデックス（たとえば、1つの整数列のみのインデックス）がMyISAMでは可変サイズのインデックスになることもあります。

理由

理由1は証拠を必要としない

まず、新しい環境を作成します。SQL文は次のようになります。

テーブルを作成するnulltesttable(
id int 主キー、
name_not_null varchar(10) nullではない、
name_null varchar(10)
) ENGINE=InnoDB デフォルト CHARSET=utf8 AUTO_INCREMENT=1;
nulltesttable テーブルを変更し、idx_nulltesttable_name_not_null(name_not_null) インデックスを追加します。
nulltesttable テーブルを変更し、idx_nulltesttable_name_null(name_null) インデックスを追加します。

select * from nulltesttable where name_not_null='name'; を説明します // explain1
説明 select * from nulltesttable where name_null='name'; // 説明2

SQL実行から、explain1ではkey_len = 32、explain2ではkey_len = 33であることがわかります。
explain1 の 32 の由来は、10 (フィールド長) * 3 (utf8 文字エンコードが占める長さ) + 2 (可変長として varchar が占める長さ) です。
Explain2 の 32 は、10 (フィールド長) * 3 (utf8 文字エンコードが占める長さ) + 2 (可変長としての varchar が占める長さ) + 1 (null マーカーが占める長さ) から得られます。

2 つの文字列を連結します。文字列に null 値が含まれている場合、結果は null として返されます。

nulltesttable(id,name_not_null,name_null) に値(1,'one',null) を挿入します。
nulltesttable(id,name_not_null,name_null) に値(2,'two','three') を挿入します。
nulltesttable から concat(name_not_null,name_null) を選択します (id = 1); -- 出力: null
nulltesttable から concat(name_not_null,name_null) を選択し、id = 2 にします。 -- 出力: twothree

フィールドが null 値を許可し、インデックス付けされている場合、次のクエリは誤った結果を返す可能性があります。

select * from nulltesttable where name_null <> 'three' -- 出力: null
nulltesttable から count(name_null) を選択 -- 出力: 1

一般に、NULL 対応の列を NOT NULL に変更してもパフォーマンスはわずかにしか向上しないため、問題が発生することが確実でない限り、既存のスキーマでこの状況を最初に見つけて変更する必要はありません。ただし、列にインデックスを作成する予定の場合は、NULL 可能となるように設計しないようにしてください。

本当に不明な値を識別する必要があるときは、 NULL を使用することを恐れないでください。場合によっては、マジック定数を使用するよりも NULL を使用する方がよい場合があります。特定の型の値の範囲から不可能な値を選択すると、たとえば -1 を使用して未知の数値を表すと、コードが非常に複雑になり、バグが発生しやすくなるだけでなく、混乱が生じる可能性もあります (注: Mysql はインデックスに NULL 値を格納しますが、Oracle は格納しません)。

もちろん例外もあります。InnoDB は NULL 値を格納するために別のビットを使用するため、スパースデータ (多くの値が NULL であり、列に NULL 以外の値を持つ行が数行のみ) の場合、スペース効率が優れています。これは MyISAM には当てはまりません。

したがって、あらゆる設計や検討では、実際のニーズに注意を払う必要があります。

これで、MySQL データベースが NULL を回避する理由に関するこの記事は終了です。MySQL が NULL を回避する方法の詳細については、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: