【要約】インデックスを貼ったはずなのに速度が改善されない！？ [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
新卒エンジニアが、タスク管理システムの表示遅延を解消しようとした際に直面した問題である。
* 複合インデックスを導入したが、ステージング環境で速度が改善しなかった。
* オプティマイザが、
*
* 結果、
* 複合インデックスを導入したが、ステージング環境で速度が改善しなかった。
* オプティマイザが、
tasksを駆動表とする誤った計画を選択した。*
tasks.statusの統計情報不足により、件数を128件（見積もり）と12,459件（実測）で誤認した。* 結果、
commentsへの高コストな行取得が約30万回発生した。// Approach
エンジニアは、
*
*
*
* ヒストグラムや
EXPLAIN ANALYZEを用いて実行計画と実測値の乖離を特定した。*
EXPLAIN ANALYZEで、見積もり行数と実測行数の乖離を確認した。*
tasks.statusに統計情報がないことが原因だと突き止めた。*
tasks.statusにインデックスを追加し、統計情報を自動更新させた。* ヒストグラムや
FORCE INDEX等の代替案と比較検討を行った。// Result
インデックス追加により、オプティマイザが最適な計画を選択した。
*
* 実行時間が約3.4秒から約0.16秒へと大幅に短縮された。
* 行取得の総回数が約30万回から6,000回未満へと激減した。
* インデックスによる統計情報の自動更新を実現した。
*
commentsを駆動表とする計画へ変更された。* 実行時間が約3.4秒から約0.16秒へと大幅に短縮された。
* 行取得の総回数が約30万回から6,000回未満へと激減した。
* インデックスによる統計情報の自動更新を実現した。
Senior Engineer Insight
> インデックスの存在は、実行計画の最適化を保証しない。本件は、統計情報の欠如が「見積もり誤差」を生み、結合順序の誤選択を招いた典型例である。大規模環境では、データの分布が実行計画を左右する。検証環境で件数のみを揃えても、統計情報の特性により計画が再現できないリスクがある。リリース後の
EXPLAIN ANALYZEによる実測確認を、標準プロセスに組み込むべきだ。