私はMySQLアップデートクエリのパフォーマンスをプロファイリングしました。定常状態の後、スループットグラフに急激な低下が見られました。私は数回テストをやり直しました。私は、突然の落とし場は、同じシナリオで同じポイントではないことに気付きました。それは時々刻々と変わる。私はこれがバッファプールのキャッシュのために起こっているのだろうか？私はMsSQLを使って同じテストをしましたが、この問題を見つけることができませんでした。この混乱で私を助けてください。MySQLアップデートクエリで突然の低下が確認されました
パフォーマンス（大きなテーブル用）はすべてディスクヒットに関するものです。そしてそのようなものを緩和するためのトリック。
SHOW CREATE TABLE、SHOW TABLE STATUS、UPDATEなどの詳細が必要です。パフォーマンスの低下はどれほど深刻ですか？ buffer_poolの大きさはどれくらいですか？ RAMの何分の一ですか？しかし、ここにいくつかの一般的な答えがあります。
「バッファの変更」は、インデックスへの書き込みをキャッシュするための手法です。 INSERTsおよびDELETEsは、最終的にすべての非固有インデックスを更新する必要があります。また、UPDATEsは、インデックス付きの列が変更された場合も同様に処理する必要があります。そのような変更は、buffer_pool内にある「バッファの変更」で収集されます。デフォルトでは、buffer_poolの25％はそのような専用です。
いくつかの変更の後で、変更バッファがいっぱいになります。この時点で、インデックスを含むBTreesを更新するには、リード・モディファイ・ライト・サイクルが必要です。このはスループットの低下として表示されることがあります。
一方、まだ更新されていないインデックスが必要なクエリはどうでしょうか？問題ない。 CBは必要に応じてチェックされます。 （I/Oを避けるために追加のCPUサイクル - 通常は勝利）
UUIDsはパフォーマンスのためにひどいです - 時には "崖から落ちた"シンドロがあります。その理由は、それらがどれほどランダムであるかによって、どのテーブルも（またはuuidインデックス）がbuffer_poolに完全に収まる大きさを超えると、どのようにキャッシュが無駄になるかです。 UUID列は通常UNIQUE（またはPRIMARY）と宣言されているため、すぐにINSERTでチェックする必要があります。つまり、変更バッファで遅延させることはできません。
UUIDを使用してテーブルを構築する場合、長い間、buffer_poolにすべてキャッシュすることができ、スループットが良好です。しかし、最終的にはテーブル/インデックスが大きくなり、必要なI/Oがうまくいかなくなります。テーブルがキャッシュ可能な20倍の大きさであれば、キャッシュの1/20しか見つからないことがあります。
約MSSql？異なるベンダーは、主要なパフォーマンス・キラー、すなわちディスクに取り組むために異なるテクニックを使用します。私はオラクルなどが何をしているのか分からない。しかし、それはおそらく異なっており、おそらくUUIDやキャッシュがいっぱいになっているためにレンガ壁のいくつかの変形にぶつかるでしょう。
（あなたが見ているもの以外の説明があります）