MySQLインデックスが失敗するいくつかの状況の分析

1. 最左プレフィックス原則 - 複数の列にインデックスが付けられている場合は、最左プレフィックス原則に従う必要があります。これは、クエリがインデックスの左端の列から開始され、インデックス内の列をスキップしないことを意味します。

前提条件: 複合インデックス (ユーザー名、パスワード、年齢) がテーブルに追加されている

分析: クエリにユーザー名がなく、クエリ条件複合インデックスの左端のユーザー名が欠落しているため、最良左プレフィックスの原則に違反し、インデックスが失敗して ALL (完全なテーブル スキャン) になります。

分析: クエリ条件にユーザー名とパスワードがありません。クエリ条件複合インデックスの左端のユーザー名とパスワードが欠落しているため、最良左プレフィックスの原則に違反し、インデックスが失敗して ALL (完全なテーブル スキャン) になります。

分析: このクエリにはユーザー名条件が 1 つだけあります。最良左プレフィックスの原則に従って、インデックスは部分的にしか使用できません。

2. インデックス列に対して操作 (計算、関数、(自動または手動の) 型変換) を実行しないでください。インデックスが失敗し、テーブル全体のスキャンが発生します。

分析: 最初のグラフインデックス列は関数を使用せず、左プレフィックスの原則に従い、インデックスを使用できます。 2 番目の図では、インデックス列に関数を使用しています。左プレフィックスの原則に従っていても、インデックスは無効のままです。

3. ストレージ エンジンはインデックス内の範囲条件の右側の列を使用できず、範囲の後のインデックスは無効になります。 （< 、> との間）

分析: 図 1 のすべてのインデックスが使用されます。図 2 では、インデックスはユーザー名と年齢を使用していますが、ユーザー名はインデックスを使用して取得され、年齢はインデックスのソートに重点を置いています。この場合、年齢は範囲検索であり、パスワード インデックスは無効になります。

4. MySQL が不等号 (!= または <>) を使用すると、インデックスが使用できなくなり、インデックスが失敗します。

5. MySQLでis not nullまたはis nullを使用すると、インデックスが使用できなくなります。

分析: ユーザー名列に通常のインデックスが作成されます。クエリには null が含まれていないため、結果のインデックスは有効ではありません。

6. MySQL では、like クエリが % で始まる場合、インデックスは無効になり、テーブル全体がスキャンされてインデックスがカバーされます。

分析: ユーザー名列に通常のインデックスが作成され、% で始まる値でクエリが実行されます。その結果、インデックスが無効になり、上書きされます。

7. MySQL では、文字列インデックスは一重引用符で囲まれていない場合は無効になります。正しい書き方: select * from t_user where username = 'lujin';

8. MySQL では、条件に or が含まれている場合、条件にインデックスが含まれていても or は使用されません (このため、 or はできるだけ使用しないようにする必要があります)。またはを使用してインデックスを有効にする場合は、または条件内の各列にのみインデックスを追加できます。

9. MySQLがインデックスよりも高速にフルテーブルスキャンを使用する場合、インデックスは使用されません。

要約する

これで、MySQL インデックス障害の分析に関するこの記事は終了です。MySQL インデックス障害に関するより関連性の高いコンテンツについては、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。