実行する一般的なクエリの 1 つで EXPLAIN ステートメントを実行しましたが、「possible_keys」がインデックス付きフィールドの 2/3 にしか一致しない理由が知りたいです。これは、LIKE 句を使用しているためですか?
これは、説明したクエリとインデックスを示す MySQL コンソールの画像へのリンクです。 http://i.imgur.com/RCWb0to.png?1
possible_keys 列にインデックスが 2 つしか表示されていないことに気付いた場合。
さらに、'key' 列に NULL が表示されるのはなぜですか? 私はこれをよりよく理解したいと思っています。これについてより詳細に読むことができる優れたリソースがそこにある場合は、リンクといくつかの情報をいただければ幸いです。
Possible_keys現在のクエリに関連する可能性のあるインデックスのみを考慮します。このクエリの役に立たない場合でも、テーブルに他のインデックスが含まれている可能性があります。
MySQL は列内の値の頻度を考慮し、行のセットを絞り込むのに役立たない値を検索しているため、インデックスを使用しないと決定する場合があります。
類推すると、本の巻末の索引を見ると、索引に「the」という単語はありません。本のすべてのページ番号をリストするだけで、無意味です。その場合、インデックスを使用する理由はなく、実際にはインデックスを使用すると検索が遅くなります。
同様に、 term を検索していますempl_id=86560 AND week_number=22が、これらの特定の値がテーブルで非常に一般的である可能性があるため、MySQL はすべての行を読み取り、一致 しない行を破棄する方が経済的であると判断します。
用語deduction_code LIKE '%VIS%'はインデックスを使用できません。類推すると、電話帳を検索して、誰かの名前の真ん中に「VIS」が含まれるすべての名前を見つけてください。本がソートされているという事実は役に立ちません。それでも、最初から最後まで検索する必要があります。
クエリkeyがこのクエリにインデックスを使用しないことを決定したため、列は NULL です。これに関するもう 1 つの手がかりは、type列に「ALL」と表示されていることです。これは、テーブル スキャンを実行し、テーブル内のすべての行を読み取っていることを意味します。
http://dev.mysql.com/doc/refman/5.6/en/explain-output.html#explain-join-typesを参照してください。
私のプレゼンテーションHow to Design Indexes, Reallyに興味があるかもしれません。
先頭に % を付けて like を使用しています。そのため、インデックスを使用できず、その列に対してフル スキャンを実行する必要があります。したがって、推論コードにインデックスを使用しません。
しかし、実際に選択されたインデックスについては、MySQL クエリ オプティマイザーはいくつかのヒューリスティックな推測を行います。また、それらのインデックスを使用するよりも全テーブル スキャンの方が高速であると判断した場合は、既存のキーを無視することを選択する場合があります。必要に応じて、mysql にインデックスを使用させることができます。詳細については、mysql のドキュメントを確認してください。
