オプティマイザは統計を見て行数を推定する。古い／偏った統計のままだと、スキャン過多や悪い結合順になり、突然遅くなる。自動更新に任せきりか、メンテジョブで触るかが運用の分岐点。
先に結論
- 大きなデータ変更のあと・バッチ後・リリース後は「遅くなったら統計」を疑う価値がある
- 自動更新は便利だが、巨大表では発火が遅く・更新自体が重いことがある
- 重要な表はメンテ枠で明示更新＋代表クエリの計画確認が安定しやすい
- フルスキャン更新は正確だが重い。サンプル率はサイズと許容時間で決める
いつ更新を検討するか
- 大量挿入・更新・削除の直後
- 夜間バッチやデータ移行のあと
- 索引再構築と合わせて計画を安定させたいとき
- 推定行と実際行が大きくズレているとき
- パラメータスニッフィング疑いの前提確認として
運用の型
- 小さい表: 自動更新でも十分なことが多い
- 大きい表: 対象を絞った定期ジョブ＋変更率の監視
- 更新中の負荷に注意（業務ピークと重ねない）
- 更新後にキークエリの計画が悪化していないかスポット確認
関連: 実行計画でインデックスが使われない
やりがちな失敗
- 全 DB を毎時フル更新（メンテがボトルネックになる）
- 遅い原因がロックなのに統計だけ触って終わる
- 更新タイミングをデプロイと重ねて計画が毎回揺れる
ざっくりまとめ
- 大量変更のあとは統計を疑う
- 巨大表は自動任せ＋明示メンテの併用
- 更新したら代表クエリで効果を確認
関連記事