単純な定数は、小さなMEMORYテーブルの主キーを非常に遅く選択します。

Question

私は、約650行、5 MBのデータ長、60 KBのインデックス長のMEMORYテーブルを持っています（かなり小さいので）。 1つのSMALLINTプライマリ（ハッシュ）キーと約90の他の列（int、varchars、datetimes、blobsまたはtexts）がありません。 （EDIT：BIGINT列のハッシュキーもあります。）

私は（PHP）からこのクエリを実行しているかなり頻繁に（約10倍の毎秒）：

選択*どこID userekから= {CONST_ID}とkitiltva = 0と kitiltva_meddig < "{CONST_DATETIME}" とinaktiv = 0

注：idが主キーです。私は*が必要です。なぜなら、結果は多くの異なる場所で使用され、基本的にはすべての列がここやそこで使用されるからです。

私の問題です：定期的にクエリが異常に遅くなる。平均して0.5sについては、8s maxです。たいていの場合、それは非常に高速です：75%の実行は、平均よりも速い3msより速く実行されます。85%しかし15%平均よりも遅い13%は1sよりも遅いです。だから、長い尾があります。

そして私はそれが何を引き起こすのか全く分かりません。誰の考え？

Answer 1

私自身の質問には申し訳ありませんが、少なくとも私は答えがあります。私は他人に役立つような方法でそれを書こうとしています。

これはMEMORYテーブルなので、I/Oの問題は除外しました。

次に、クエリはプライマリキーによって選択される単純（const）なので、インデックス作成の問題にはなりません。

次の推測はロックされていました。この表のアプリケーションでは、非常に遅い選択があります。そしてそれは問題になる可能性があります：遅い選択は、他の選択を遅らせる遅延更新を選択します。したがって、この非常に簡単で迅速な選択を遅らせることができます。

slow query logを確認したところ、この特定のテーブル（およびその他のテーブル）を使用していた2つの頻繁な選択と低速の選択が見つかりました。ひどく形成されたケースに参加した原因：

A left join B on case 
when A.x=1 then B.id=A.id2 
when A.x=2 then B.id=A.id3 
else B.id=0 
end 

代わりに

A left join B on B.id = case 
when A.x=1 then A.id2 
when A.x=2 then A.id3 
else 0 
end 

両方が同じ結果を与えるが、後者は、前者ができない、B.idのインデックスを使用することができます。

これらのクエリを修正すると、オリジナルのクエリのパフォーマンスが平均で500msではなく5msと大幅に向上しました。そして平均よりも速い98%。

道徳的：

• 使用slow query log、それを分析し、あなたが常に同じにロックすることにより、あなたのクエリを遅くする「交差点」クエリをチェックし、不可解なスローダウンが発生した場合、低速のクエリ
• を改善テーブル