2

MySQL (5.1.66) の説明を使用すると、72 行だけをスキャンすると言いますが、「スロー ログ」ではテーブル全体がスキャンされたと報告されます (Rows_examined: 5476845)。クエリの何が問題なのかわかりません

*name*文字列の一意のインデックスであり *date*、通常の int インデックスです

これが説明です EXPLAIN SELECT * FROM table WHERE name LIKE 'The%Query%' ORDER BY date DESC LIMIT 3;

id select_type テーブル タイプ possible_keys キー key_len ref 行 エクストラ
1 SIMPLE テーブル インデックス名 日付 4 NULL 72 where の使用

スローログからの出力

# Query_time: 5.545731 Lock_time: 0.000083 Rows_sent: 1 Rows_examined: 5476845 SET timestamp=1360007079; SELECT * FROM table WHERE name LIKE 'The%Query%' ORDER BY date DESC LIMIT 3;

4

1 に答える 1

4

rowsから返される値は、クエリに一致する結果を見つけるために調べる必要のある行数のEXPLAIN見積もりです。

見てみると、クエリの実行に選択されているキーはであることがわかりますdate。これは、おそらくORDER BY句が原因で選択されています。クエリで使用されているキーは句とは無関係であるWHEREため、見積もりが混乱しているのはおそらくそのためです。WHERE句が列に対してを実行している場合LIKEでも、nameオプティマイザはインデックスをまったく使用しないことを決定する場合があります。

MySQLは、インデックスが使用可能であっても、インデックスを使用しない場合があります。これが発生する状況の1つは、オプティマイザが、インデックスを使用するとMySQLがテーブル内の行の非常に大きな割合にアクセスする必要があると推定した場合です。（この場合、必要なシークが少ないため、テーブルスキャンの方がはるかに高速である可能性があります。）ソース

つまり、オプティマイザーは、name返される行の制限要因となるキーであっても、キーを使用しないことを選択しています。インデックスを強制して、パフォーマンスが向上するかどうかを確認できます。

于 2013-02-04T20:16:23.290 に答える