4

MySQL クエリのパフォーマンスを調整しようとしていますが、理解できない (したがって修正できない) 問題が発生しています。基本的に、大きなテーブルのサブセットである場合よりも、独自のテーブルにある場合の方が、165,000 行を高速に並べ替えることができます。

テーブル fl6 には 200 万行あります。(departure_out) にインデックス x1 があります。Departure_out は日付タイプです。

次の select は、165,916 行を検索します。0.1秒かかります。

select count(*) 
from fl6 
where departure_out > "2013-04-01" 
and departure_out < "2013-04-05";

次の select には同じ where 句がありますが、価格で並べ替えます。0.5秒かかります。165,000 行の並べ替えに 0.4 秒。 

select id 
from fl6 
where departure_out > "2013-04-01" 
and departure_out < "2013-04-05"
order by price_total limit 1;

高速化できるかどうかを確認したかったので、165,916 行だけを含む小さなテーブルを作成しました。それから私はそれについてソートしました。0.16秒かかりました。 

select id 
from fl6_small
order by price_total limit 1;

つまり、165,000 行をかなり高速に並べ替えることができますが、大きなテーブルのサブセットの場合は 2 倍以上の時間がかかります?? どうすればそれを行うことができますか？違いはなぜですか？

いくつかのこと：私はすでに（価格）と（departure_out、価格）にインデックスを付けようとしました。それは違いはありません。いずれにせよ、fl6_small での検索でインデックスがなくてもソートできる速度が示されている場合は、インデックスを使用する必要はありません。

編集：

(Explain Plan に使用される表に一致するように、上記の行数と時間の一部を編集しました)

説明計画:

+----+-------------+-------+-------+---------------+------+---------+------+--------+-----------------------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows   | Extra                       |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-----------------------------+
|  1 | SIMPLE      | fl6   | range | x1            | x1   | 3       | NULL | 160493 | Using where; Using filesort |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-----------------------------+
4

3 に答える 3

1

違いは、最初のケースでは、MySQL が 165000 行で一時テーブルを作成し、インデックスなしでそれらをソートすることです。価格列にインデックスがあっても、ソートには使用できません。

小さなテーブルでは、並べ替えにインデックスを使用できる可能性があるため、はるかに高速です。

于 2013-02-13T12:18:23.247 に答える
0

EXPLAINステートメントを使用して、クエリhttp://dev.mysql.com/doc/refman/5.0/en/explain.html およびhttp://dev.mysql.com/doc/refman/5.0/のボトルネックを確認できます。 en /optimization.html

于 2013-02-13T10:44:04.737 に答える
0

これは、いくつかの問題が原因である可能性があります。

気の毒な点-大きなテーブルでは、単純な並べ替え以上のことを行っています。最初にレコードを探し、次に並べ替えます。小さなテーブルでは、depature_timeで検索しませんでした。しかし、それはちょっとした不正行為です。テーブルが大きいので、どのnを使用するかを知るために、最初にテーブルを作成する必要があります。ただし、インデックスが作成されている場合は、テストが示すようにそれほど重要ではない可能性があります。それでも、0.5秒のうち0.1秒かかったようです。小さなテーブルのwhere句も試してください。少し時間がかかるはずです。そうでない場合は、次のことを示します。

第二に、*キャッシュミス： *

2,000Kレコードは、使用しているマシンの150Kレコードを大幅に超える可能性があります。ただし、mysql専用のボックスがない限り、キャッシュミスの可能性が高くなります。これらのミスは、^ 2ソート以下のレコードがメモリにロードされ、メモリが整列されている場合でも、はるかに大きなペナルティになる可能性があります。ラムが多いボックスでこれらのテストを実行する場合、他のすべてが等しいと仮定すると、不一致は少なくなるはずです。

于 2013-02-13T13:51:20.643 に答える