私は遅いMySQLクエリを繰り返し最適化しようとしています。つまり、クエリを実行し、タイミングを取得し、調整し、再実行し、タイミングを取得します。問題はタイミングが非定常であり、クエリの実行は、以前の実行とはまったく異なる動作をします。MySQLクエリを繰り返し最適化するには？
私は、実行の間にクエリキャッシュをクリアしたり、オフにすることを知っています。また、あるレベルでは、OSがMySQLの制御や理解できない方法でクエリのパフォーマンスに影響を与えることも知っています。しかし、一般的に、私はこの種の反復クエリ最適化を行うことができますので、私はリンゴとリンゴを比較できますか？
クエリ最適化ツールは、EXPLAINです。 learn what the output meansには少し時間がかかりますが、その後、MySQLの（ひどい、壊れた、後ろ向きの）クエリプランナーが要求されたデータを最もよく取り出す方法を理解することができます。
クエリのパラメータが変更されると、クエリプランが大きく異なる可能性があります。そのため、表示されている問題の一部が説明されている可能性があります。
あなたは低パフォーマンスで実行される可能性がありますすべてのクエリをキャプチャするを検討する必要があります。おそらく、特定のパラメータを使用する場合、問題のクエリは低いパフォーマンスのカテゴリに該当するだけでしょうか？
EXPLAINに関するヒントをありがとう - 大きな助けになるでしょう。私はすでに低速のクエリログを精査していますが、これは最終的に私がより強く押す必要があるかもしれないと思うかもしれません：遅いクエリのコーパスを構築し、バッチでそれらを実行し、スロークエリーログへのアクセスは、私が私のコメントで説明したキャッシング効果に堅牢なパフォーマンスを生み出すには十分に異なっています（下記参照）。 – shanusmagnus
@shanusmagnusもしこれが単にディスクブロックキャッシング（またはその欠如） MySQLの設定を調べて、指定されたデータベースサイズに対して、そのハードウェアですでにパフォーマンスが調整されているかどうかを判断する必要があります。 Perconaの[MySQL Performance Blog]（http://www.mysqlperformanceblog.com/）が興味深いかもしれません。 – Charles
クエリを1000回実行するスクリプトを作成するか、結果を安定させる反復回数を指定します。
次に、上記の手順に従いますが、1回の実行に頼るのではなく、複数回の実行が平均的であることを確認してください。正しいので、行数が変化すると結果が安定しませんあなたのマシンは他のことをしています。
また、ユースケースに合っていれば、さまざまな入力をクエリに使用してみてください。
これは一般的に良いアドバイスですが、悲しいことに、私の特別なケースでは役に立ちません。その場合、1回のクエリで後続のクエリで実行時間が25秒から700ミリ秒になります。明らかにキャッシュは機能しており、関連するディスクブロックにOSレベルのキャッシュがあるようです。 「十分に異なる」同じ種類のクエリは、実行時間を25秒の範囲に戻すことができますが、この方法でシステムを実行するのに十分なクエリを自動的に作成するのは自明ではありません。 – shanusmagnus
あなたは 'SELECT SQL_NO_CACHE ...'を試しましたか？これは通常、多くの実行でクエリの実行時間を安定させるのに十分です。 – Galz
私はしていない、私は、し、私は戻って報告します。ありがとうございました。 – shanusmagnus
さて、試してみました。効果はありません。最初のクエリの後にパフォーマンスが向上したら、クエリは高速になります。しかし、ヒントのおかげで、これは他のコンテキストで知っておくと便利です。 – shanusmagnus