インデックスフィールド+リミット1対パフォーマンスの点でユニークなフィールド比較| MySQL

Question

例1フィールドc.aliasは一意です。

Select c.* from category c where c.alias = 'some-alias' 

例2フィールドc.aliasは、単にインデックス付けされます。

Select c.* from category c where c.alias = 'some-alias' limit 1 

これらの2つの例では、クエリのパフォーマンスが異なりますか。

Answer 1

あなたの質問に対する答えは、テストして調べることです。

しかし、違いがある場合、私はそれが非常に、非常に小さいと期待します。いずれの場合も、where句にインデックスを使用する必要があります。あなたは本当にMySQLが最初のマッチ後に停止することを "知っている"かどうかを尋ねています（ユニークなインデックスのためです）。 MySQLは、それが異なることを知るために次の値を調べる必要があります。この第2ステップは、ほとんどオーバーヘッドを持ちません。

これは、コードの最適化に関する深刻な質問の場合は、間違った場所を探している可能性があります。このようなマイクロ最適化（おそらくナノの場合）は通常役に立ちません。

プライマリキーインデックスと通常のインデックスを比較すると、大きな違いが生じることに注意してください。 MySQLでは、プライマリキーが自動的にクラスタ化され、パフォーマンスの差は小さくても測定可能です。

Answer 2

（ゴードンの答えは良いです。しかし、私は言いたいことがいくつかの異なるものを持っている...。）

SELECT ... WHERE unique_col = constant - これはテーブルから（もしあれば）1行を読み込みます。 LIMIT 1は、些細な解析時間以外の影響はありません。

SELECT ... WHERE non_uniq_col = constant - これは、一致しない行が見つかるまで読み取ります。つまり、N行を読み込むためにN + 1行を読み込みます。この場合、LIMIT 1はそれを止めるでしょう。今質問はパフォーマンスに関するものではありません（Nが小さい場合はあまり違いはありません）が、機能については（1行またはNが必要ですか？）

InnoDBでは、PRIMARY KEYはデータで「クラスタ化」されており、暗黙的にはUNIQUEです。それは上記の通りです。

セカンダリキーでは、追加のステップがあります。最初に、のインデックスBTreeの行が見つかりました（col=const）。そのBTreeのリーフノードには、目的の行のPKがあります。余分なステップは、行を見つけるためにPKのBTreeをドリルダウンすることです。これはいくらか余分なコストがかかりますが、中小規模のテーブルではあまり心配する価値はありません。 （LIMIT 1の問題は、まだ適用され、マイナーです。）SELECTで参照されるすべての列が（PKの暗黙のコピーを含む）と同じセカンダリインデックスにある場合

を、そしてインデックスが」と言われていますカバーする "。したがって、クエリは、二次インデックスのBTree内で完全に実行され、それによって余分なステップが回避されます。繰り返しますが、これは通常小さいですが、行う価値があります。 「カバーリング」はEXPLAINに「インデックスの使用」（「インデックス条件の使用」ではなく、別のものを指す）で示されています。

私はIndexing Cookbookを学ぶことをお勧めします。私の文書はあなたにパフォーマンスのために重要なことを与え、この質問が議論しているような重要ではない詳細のいくつかを除外します。

小規模ののテーブルの場合、これらはいずれも重要ではありません。
巨大なテーブルでは、ディスクヒット数が主要なパフォーマンスメトリックです。それを最小化することが目標になります。特に、セカンダリインデックスのための余分なステップは、通常、N個のディスクヒット（N個の行）を必要とします。

しかし... SELECT ... GROUP BY ... ORDER BY ... LIMIT 1は、一群の行を取り出し、並べ替え、最後に1行を配信することがあります。 インデックスでソートを使用できない場合は、N行が多分操作されます。 のケースでは、努力の99％が費やされた後にのみ、LIMIT 1が動作します。これは、初心者のためのLIMITについてのよくある誤解です。