レポートの必要性に応じて、多くの MySQL 選択クエリがあります。ほとんどは少し複雑で、通常は 1. 5 ～ 6 個の結合ステートメント 2. select 句の 3 ～ 4 個の内部クエリが含まれます。
すべてのインデックスが本番環境に適切に配置されています。クエリ構文の説明を何度も確認しましたが、問題ありません。
一部のクエリは、応答時間に関して非常に奇妙な動作をします。同じクエリが 500 ミリ秒未満で返されることもあり (すべてのインデックスが正常に動作していることを示しています)、1 分ほど後に実行すると、応答時間が長くなります (5 ～ 6 秒から 30 秒まで変化します)。 .) しばらく (20 回に 1 回程度..) タイムアウト エラーが発生します。
これはサーバーの負荷が原因である可能性がありますが、分散が非常に頻繁に発生するため、それを解決するには別の設定が必要であると考えられます。
他に何をすべきかについての指示を教えてください！
ありがとう、
サミット
この種の動作は通常、スタック内のボトルネックが原因です。
建物の回転ドアのようなものです。ドアは一度に 1 人を処理でき、1 人あたり 3 秒かかります。3 秒ごとに 1 人を超える割合で人が到着しない限り、それがボトルネックであることはわかりません。人々が短期間早く到着した場合、キューは少し大きくなりますが、すぐに消えます。1 時間に 2.5 秒ごとに 1 人の割合で人々が到着すると、待ち行列は手に負えなくなり、消えるまでに 1 時間よりもはるかに長い時間がかかる可能性があります。
データベース システムは、回転ドアのある長い廊下で構成されています。ほとんどのドアは並行して動作できますが、制限があります。
(くだらない類推で申し訳ありませんが、現実世界の画像でこれらのことを視覚化するのに役立ちます)。
クエリのパフォーマンス プロファイルに大きなばらつきがある場合は、システム パフォーマンス モニター (Linux ではトップ、Windows では Perfmon) を調べて、パフォーマンスの低下をシステムの動作と関連付けてみます。クエリの速度が低下したときに CPU 使用率が急激に上昇する場合は、それがボトルネックである可能性があります。ディスクのスループットが急上昇した場合は、そこを確認してください。
ボトルネックについて仮説を立てたら、それらを解決する方法を検討できます。通常、問題にハードウェアを投入するのが最も安価です。