同じ手続き・同じパラメータ化文なのに、ある値では速い・別の値では極端に遅い——典型がパラメータスニッフィング。初回コンパイル時の値向け計画が、別の分布の呼び出しに再利用される。
先に結論
- 症状: 「昨日まで速かった」「特定の条件だけ遅い」「再起動や計画クリア後に様子が変わる」
- まず実測の実行計画と、想定行数と実行数のズレを見る
- 対処は再コンパイル強制・最適ヒント・局所変数化・計画ガイド等。闇雲に全部再コンパイルは最終手段寄り
- 統計が古いとスニッフィング以前に計画が崩れるのでセットで確認
切り分け
- 速いケースと遅いケースの実パラメータを控える
- 両方の実計画を比較（探索／スキャン、結合種類）
- 推定行と実際行の差が大きいか
- キャッシュされた計画の「嗅いだ」値と、遅い呼び出しの値が乖離していないか
- 統計の更新日時・ヒストグラムの偏りも見る
よく使う対処の型
- 該当文だけ再コンパイル（全体クリアは副作用大）
- OPTIMIZE FOR / UNKNOWN 系で寄せたい分布を指定
- 局所変数に一度入れてコンパイル時推定を平均寄りにする（トレードオフあり）
- 索引・統計の見直しで「どの値でも破綻しにくい」計画にする
関連: 実行計画とインデックス
やりすぎ注意
- 全手続きに再コンパイル指定 → CPU 増・コンパイル嵐
- 計画キャッシュ全削除を常套手段にする
- 症状が統計・欠損索引なのにスニッフィング名目でヒント追加
ざっくりまとめ
- 値によって計画が合わないのが本質
- 速い／遅いの計画比較が最短
- ヒントは局所的に。統計と索引も同時に見る
関連記事