SQL Serverオプティマイザと選択する実行プラン の触り。

SQL Server2008 SP1にてクエリが重くてサイトダウン寸前な状況に。
開発・STGででなくて本番でいきなりなったのでそんな状態になって調査が飛んできた。
今回ばかりはManagementStudioの実行プランとMicrosoftのTechNetの二つにすがりました。
つかSQL Server自体初めてなので一から勉強。
とにかく実行プランを全部読みといてみた。

【調査1日目】
まず開発・STG環境で実行したプランと本番で実行したプランでクエリが対象にしてたデータ量がめっちゃ違う。
view参照クエリだったんですが、本番では約800万と約60万のMergeJoinが開発・STGでは約150と約30。
そもそもSTGのデータ量が本番と違うのなんでって事を突っ込みたい。
なのでまず検証環境を用意。

【調査2日目】
本番とほぼ同じデータ量の環境で再度実行。
でも再現せず。
むしろ開発・STGで実行されてる実行プランと同じプラン選択してる。
おかしいなと思って再度本番でクエリ実行したらこちらも再現しない。
開発・STGで実行されてる実行プランと同じプラン選択してる。
キャッシュか何か？と思ったけど、前日本番で何度実行しても遅い実行プラン選択してたからそんなわけない。
昨日から何か変わったのか？と思い返してはた、と。
そういえばインフラの人からメールでSQL Server2008 SP2にするってメールが来てた。

●以下予想。。
ワケがわからなくて詳しい人に助けを求めてたてた予想。
再起動して速い実行プランが選択されたって事は、そもそものデータ量で実行プランの選択が左右されていたわけではなく、別の要因で実行プランが選択されていた、と思う。
その別の要因がサーバ再起動の影響を受けるモノであるとすると、クエリオプティマイザが参照していた統計情報では？
(SP2に上げた事で影響を受けたモノかも？そうなるとSP1からの変更点はなんだろう？)
(そもそも統計情報はサーバー再起動のタイミングでクリアされるものなのだろうか？)
統計情報がクリアされてオプティマイザが新しく実行プランを組み立てて速いプランを選択したのであれば、本番で遅い実行プランを選択していたのはデータ量が違うからではなくて古い統計情報を参照して選択したプランだったから？
結構頻繁にカラム追加等がテーブルにされているのだが、スキーマまでは統計情報の保守に含まれていないため、古い統計情報と新しい統計情報の違いが生まれてしまったのではないだろうか？
そうするとオプティマイザが維持する統計情報はいつ何をとってきているのだろうか？

興味深い内容だったので流れ残しときます。
予想少しでも裏付けられるように引き続き調査中。