EXPLAIN で詰まったときの三つ目の手札、Optimizer Trace の話 - Timee Product Team Blog

はじめに こんにちは。プラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 MySQL が遅いとき、まず EXPLAIN で計画を見る。見積もりが怪しければ EXPLAIN ANALYZE で実測と突き合わせる。たいていのケースはこの二つで十分で、実際自分もそれで困ったことはほとんどありませんでした。 ところが先日、この二つをいくら眺めても答えが出ない場面に当たりました。最後に頼ったのが Optimizer Trace でした。普段のチューニングではまず使わないので、すっかり引き出しの奥にしまっていた手札です。そこに至るまでの経緯も含めて書いておきます。 まず、何が起きていたか Aurora MySQL を 3.04.2（8.0.28 互換）から 3.10.3（8.0.42 互換）にアップグレードしたら、通知配信バッチの特定クエリが 4,000〜5,000

[tmtms]

これか。MySQL のオプティマイザは賢くないけど、パッチレベルでは振る舞い変わって欲しくないよねぇ… https://bugs.mysql.com/bug.php?id=117770

[mkusaka]

MySQLの遅延調査でEXPLAIN/EXPLAIN ANALYZE後にOptimizer Trace活用。Auroraで4,000〜5,000秒滞留要因を特定。

[sunakawa]

Optimizer Trace

[clubman023]

へー

[tkysktmt]

“EXPLAIN 系だけだと「変な計画が選ばれる」までしか言えませんが、Trace を読んだことで「確定処理の再チェックで range が捨てられている」と書けるようになりました”

[t_f_m]

"「コスト計算で選ばれた range が確定処理で消えている」というのは、どう考えても正常な最適化には見えません。Trace の該当箇所を添えて AWS サポートに問い合わせたところ、実体化経路については MySQL の既知バグに該当"

[rgfx]

そんなことあるんだ(おもしれーーー)