0

私は単純なクエリを持っています - それは1つのテーブルだけを見て、インデックス付けのための2つの列、ErrorTypeId (約20の一意の値のルックアップテーブルを指します) とDateOccurred (任意の日付を含む可能性のある日時列) の選択肢があります。 .

ほとんどの場合は問題ありませんが、特定のシナリオではクエリがタイムアウトします。調べてみると、選択されたインデックス (ErrorTypeId) は、他のインデックス (DateOccurred) よりも計画内の行数が少ないですが、何らかの理由で、手動で強制的に他のインデックスを使用する場合よりも実行に時間がかかります。

/* This execution plan has fewer rows than the second one - and as a result this is
 * the one chosen.  But it is much much slower.
 */
EXPLAIN
SELECT * FROM my_log_table
WHERE DateOccurred BETWEEN '2013-06-11 00:00:00' AND '2013-06-22 00:00:00' AND ErrorTypeId = 4
ORDER BY DateOccurred DESC
LIMIT 1000;


/* Many more rows - but much much quicker to execute. 
 * Is it the spread of data across pages?  Is there a
 * way other than USE/FORCE INDEX to improve execution plan?
 */
EXPLAIN
SELECT * FROM my_log_table USE INDEX (DateOccurred_Index)
WHERE DateOccurred BETWEEN '2013-06-11 00:00:00' AND '2013-06-22 00:00:00' AND ErrorTypeId = 4
ORDER BY DateOccurred DESC
LIMIT 1000;

参照する行が多いと、2 番目のクエリが高速になるのはなぜですか?

USE/FORCE インデックスを使用せずに MySql がより高速なインデックスを選択できるようにする方法はありますか?

4

1 に答える 1

0

クエリが遅い理由は、非効率的なインデックス作成です。

複合インデックスを追加する(ErrorTypeId, DateOccurred)と、強制やヒントは必要ありません。

于 2013-06-26T07:33:27.753 に答える