table_nameテーブルに 20 の異なる値しか持てないフィールドがあります。テーブル内の総レコード数は、数万行程度です。次のようなクエリを実行すると:
SELECT * FROM table WHERE table_name = 'adasd';
返されるレコードは最大で合計行の 25% です。ほとんどの場合、全レコードの 10% しか取得できません。ここにフィールドをインデックス化するスコープはありtable_nameますか? インデックスがうまく機能するには、そのフィールドの値が一意であるか、それに近い値である必要があると聞きました。私の場合、それはまったくユニークではありません。しかし、返された行の数が行の総数に比べて少ない場合は、インデックス作成に適しているとも聞きました。
これについてどうすればよいですか？
いいえ、インデックスを使用してメリットを得るために一意である必要はありませんが、クエリを処理するときに DBMS が何をするかを考えるのに時間がかかります。
フル テーブル スキャン - データの順次読み取り (シーク操作がほとんどない)
インデックス ルックアップ - 選択したデータの開始点を見つけるためにインデックスを数回シークし、次に基になるテーブルの行を識別するためのシーケンシャル読み取り (数回のシーク)、そしてテーブルから行をフェッチするための非常に多くのシーク
シークは高価です。
(完全なテーブル スキャンには、キャッシュからホット データをフラッシュする傾向があるという二次的な影響がありますが、最初に主要な問題に対処する必要があります)。
この場合、インデックスが存在する場合、DBMS がそのインデックスを使用する可能性は低く、使用したとしても、テーブル全体のスキャンよりも遅くなる可能性があります。(非常に) 大まかな経験則として、述語が行の約 5% 未満を識別する場合にのみ、インデックスからメリットが得られます (ただし、インデックスとデータの相対的なサイズによって異なります)。 ）。
つまり、このフィールドだけにインデックスを追加する必要はありません。
なぜそんなに多くの行を返すクエリを実行する必要があるのかを考えるのに時間がかかると思いますか?
インデックスを作成しても、MySQL がそれを使用するわけではないことを知りました。それを念頭に置いて、私は私の答えを言い換えます：
(一般的または独自の) 慣行で推奨される場合は、その列にインデックスを作成する必要があります。MySQL はヒューリスティックを使用します。これには、使用可能なインデックスとそれぞれのカーディナリティを調べて、使用するのに最適なインデックスを決定するか、インデックスをまったく使用しないかを決定することが含まれます。
このトピックに関する興味深い読み物はこちら.