MySQL8.4は「速くなった」のではなく遅くなりにくくなった
MySQL8.4にアップグレードした人の感想は、実は少し似ています。
「劇的に速くなったわけではないが、急に遅くなることが減った」
これは感覚的な話ではありません。
MySQL8.4の改善は、ピーク性能ではなく安定性能に集中しています。
つまりベンチマークの最高値を上げたというより、
本番運用で起きる「突然の遅延」を減らす方向の改良です。
まず前提：MySQLの遅さの多くはクエリではない
多くの人は、MySQLのパフォーマンス問題を次のように考えます。
- SQLが悪い
- インデックスが足りない
- CPU不足
もちろん間違いではありません。
しかし本番環境の「突然の遅さ」は別の要因が多いです。
- ロック待ち
- ディスクI/O待ち
- バッファ競合
- 統計情報の不一致
MySQL8.4は、この領域に手が入っています。
InnoDBのロック競合の改善
特に影響が大きいのがInnoDBの内部ロックです。
従来のMySQLでは、同時更新が増えると次の現象が起きました。
- CPU使用率は低い
- なのにレスポンスが遅い
これはロック待ちです。
スレッドが処理ではなく待機していました。
MySQL8.4では内部ラッチ処理が改善され、
高並列時の待ち時間が減少しています。
結果として、アクセス集中時のレスポンス低下が緩やかになります。
統計情報（オプティマイザ）の改善
MySQLの実行計画は統計情報に依存します。
この統計が古いと、誤ったインデックスを選択します。
その結果、次の状態が起きます。
- ある日突然遅くなる
- 再起動で直る
これはバグではなく、統計の偏りです。
MySQL8.4では統計収集とヒストグラムが改善され、
実行計画のブレが減りました。
つまり「昨日まで速かったのに今日遅い」が起きにくくなります。
I/O処理の改善
もう1つの重要な変更がディスクI/Oです。
MySQLはディスク書き込みのタイミングで待ちが発生します。
特に次の場面です。
- COMMIT
- バックグラウンドフラッシュ
- チェックポイント
8.4ではフラッシュ処理の分散が改善され、
書き込み集中による停止時間が短くなりました。
これにより、書き込みの多いサービスで効果が出やすくなっています。
パフォーマンススキーマの強化
トラブルシュート面でも変化があります。
従来は「遅い原因が分からない」ことが多く、
調査にはログ解析や推測が必要でした。
MySQL8.4では、待機イベントの可視化が進みました。
SELECT * FROM performance_schema.events_waits_summary_global_by_event_name ORDER BY SUM_TIMER_WAIT DESC;
どこで時間を消費しているか確認できます。
これは性能向上というより、障害対応の改善です。
注意点
8.4に上げれば必ず速くなる、というわけではありません。
特に次のケースでは差が出にくいです。
- 小規模データ
- 単一ユーザー
- 読み取り専用処理
改善の多くは「競合状態」で効果が出ます。
テスト環境では分かりにくい変更です。
また、実行計画が変わる可能性もあります。
アップグレード後は必ずEXPLAINを確認した方が安全です。
なぜこの方向の改善なのか
最近のデータベースの課題は「速さ」より「予測不能な遅さ」です。
CPUやSSDは高速になりました。
しかし同時アクセス数はそれ以上に増えています。
ボトルネックは処理能力ではなく競合です。
MySQL8.4は、ピーク性能を追うのではなく
「遅くなる瞬間を減らす」設計に近づいています。
どう評価すべきか
MySQL8.4の改善は、ベンチマークだけを見ると地味に見えます。
しかし実運用では意味が大きい変更です。
システム障害の多くは平均性能ではなく、
一時的な遅延から始まります。
つまり8.4は「速いデータベース」というより、
止まりにくいデータベースに近づいたバージョンです。
アップグレードの判断は、性能向上よりも
運用安定性の観点で考える方が実態に合っています。
