先日、某運用サービス環境（商用です...）のデータベース（MySQL）のバージョン5.5がサポート終了なる死刑宣告を受け急遽、エンジンのメジャーバージョンアップを行うこととなりました。
商用サービスですので、まずは軽く各メジャーバージョンの仕様変更ポイントを確認、検証向けの環境で予行演習と動作検証を行いました。
疎通と端末アプリに特異動作はみられず、DBのバイタルにも特に問題が見られなかったため、商用適用作業は完了。
しかし数日後、特定の画面表示タイミングで大幅なパフォーマンス劣化が報告され調査開始。
サーバモジュール、端末アプリ双方には特段異常を確認できず、クラウド上の管理コンソールに出力されるスロークエリにも特に出力なし...
念のためDBにターミナル接続しスロークエリを直接確認したところ、ポロポロと軒並み5秒以上コストがかかっているクエリを特定しました。
実行計画をexplainコマンドで確認すると、インデックスの使われ方、結合順に以前と明らかな差分。
テーブルのデータ断片化解消や統計情報の再計算にとる実行計画の変化、そもそものインデックスの貼り方などをチェック、検証しました。
参考）https://techblog.yahoo.co.jp/entry/2020052530001949/
そうこうしても実行計画には特に変化なし、、そしてオプティマイザ周りの情報を収集しているうちに、、見つけました ... optimizer_switch の 「condition_fanout_filter」と「deriverd_merge」。
※ deriverd_merge の公式説明から実行計画の変化をイメージするのは難しい… X-(
結論）インデックスの貼り方、表の結合方法、オプティマイザ周りの仕様変更には気をつけて。
以上です。