MySQLはインデックスとの照合をどのように使用しますか？

Question

インデックスを生成するときにMySQLが照合順序を取るかどうか、または照合順序に関係なく同じインデックスが生成された場合、その照合は後でそのインデックスをトラバースするときにのみ考慮されます。

私の目的のために、フィールドに照合utf8_unicode_ciを使用したいと思います。私はこの特定の照合が比較的高いパフォーマンスのペナルティを持っていることを知っていますが、それを使用することはまだ私にとって重要です。

私はORDER BY句を満たすために使用されているそのフィールドに索引を持ち、すぐに行を検索します（ファイル・ポートを避ける）。しかし、この照合を使用すると、索引から読み取った行の速度に影響するかどうか、または索引がその照合順序に従ってデータをすでに正規化された状態で格納しているかどうかはわかりません。完全にインデックスを生成してそれを読み返すことはありません。

Answer 1

私は、列の値を違う方法で比較する必要があるため、btree構造が異なると考えています。

これら2つのクエリプランを見てみましょう。

mysql> explain select * from sometable where keycol = '3'; 
+----+-------------+-------+------+---------------+---------+---------+-------+------+--------------------------+ 
| id | select_type | table | type | possible_keys | key  | key_len | ref | rows | Extra     | 
+----+-------------+-------+------+---------------+---------+---------+-------+------+--------------------------+ 
| 1 | SIMPLE  | pro | ref | PRIMARY  | PRIMARY | 66  | const | 34 | Using where; Using index | 
+----+-------------+-------+------+---------------+---------+---------+-------+------+--------------------------+ 


mysql> explain select * from sometable where binary keycol = '3'; 
+----+-------------+-------+-------+---------------+---------+---------+------+-------+--------------------------+ 
| id | select_type | table | type | possible_keys | key  | key_len | ref | rows | Extra     | 
+----+-------------+-------+-------+---------------+---------+---------+------+-------+--------------------------+ 
| 1 | SIMPLE  | pro | index | NULL   | PRIMARY | 132  | NULL | 14417 | Using where; Using index | 
+----+-------------+-------+-------+---------------+---------+---------+------+-------+--------------------------+ 

我々は比較のための照合順序を変更した場合、突然、それももう指数を追求することができず、すべての行をスキャンする必要があります。大文字小文字を区別するか、大文字と小文字を区別しない照合を使用しているかどうかにかかわらず、元の大文字で値を返すなど、照合に関係なくインデックスに格納される実際の値は同じになります。

大文字小文字を区別しない照合に対するルックアップは、やや効率的ではありません。

しかし、私はあなたがこれまでの違いに気付くことはできないだろうかと疑っています。 MySQLはデフォルトで大文字と小文字を区別しないため、影響はそれほど深刻ではありません。

UPDATE：クエリを実行するために必要な余分な 'filesortレコード' のステージ

mysql> explain select * from sometable order by keycol collate latin1_general_cs; 
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-----------------------------+ 
| id | select_type | table | type | possible_keys | key  | key_len | ref | rows | Extra      | 
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-----------------------------+ 
| 1 | SIMPLE  | pro | index | NULL   | PRIMARY | 132  | NULL | 14417 | Using index; Using filesort | 
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-----------------------------+ 

mysql> explain select * from sometable order by keycol ; 
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-------------+ 
| id | select_type | table | type | possible_keys | key  | key_len | ref | rows | Extra  | 
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-------------+ 
| 1 | SIMPLE  | pro | index | NULL   | PRIMARY | 132  | NULL | 14417 | Using index | 
+----+-------------+-------+-------+---------------+---------+---------+------+-------+-------------+ 

注：

あなたは操作でオーダーについても同様の効果を見ることができます。つまり、mysqlは結果を一時バッファに格納し、余分なステージでクイックソートを使ってそれをソートし、インデックスの順序が何であってもそれをスローします。元の照合順序を使用すると、mysqlはインデックスからの順序を最初に知っているので、このステップは不必要です。

Answer 2

MySQLは、インデックスの列の照合を使用します。したがって、あなたがutf8_unicode_ciフィールドを作成した場合、そのインデックスはutf8_unicode_ciの順序で有効になります。

インデックスを使用しても、パフォーマンスの影響を100％回避するとは限りませんが、ほとんどの実用的な目的のために使用されます。

多くのデータベースシステムはCPUにバインドされていないため、その影響に気づくことはできません。