はじめに
SQL Serverでは、クエリの実行プランを最適化するために「統計情報（Statistics）」が使われています。 この統計情報は、通常自動更新（AUTO_UPDATE_STATISTICS）が有効になっており、データの変更に応じて自動的に更新される仕組みです。
そのため、特別な事情がない限り、統計情報の更新を意識することは少ないかもしれません。 しかし、ある日「自動更新されているはずなのに、クエリが急に遅くなった」という現象に遭遇しました。
発生した問題
あるテーブルに対して、いつも通りのSELECTクエリを実行したところ、普段は数秒で終わる処理が、なぜか数十秒以上かかるようになっていました。
インデックスも適切に設定されており、統計情報の自動更新も有効な状態。 それでも、クエリのパフォーマンスが明らかに落ちていたのです。
試したこと
深く調査する時間がなかったため、まずは試しに以下のコマンドを実行してみました：
UPDATE STATISTICS dbo.対象テーブル名 WITH FULLSCAN;すると、クエリの実行時間が大幅に短縮され、元のパフォーマンスに戻りました。 統計情報を手動で更新しただけで、ここまで変わるとは正直驚きでした。
なぜFULLSCANで改善したのか？
SQL Serverの自動統計更新は、サンプリングベースで行われます。 つまり、全データを対象にするのではなく、一部のデータをサンプルとして統計を作成します。
この方法は軽量で高速ですが、データに偏りがある場合や、急激なデータ変更があった場合には、正確な統計が得られない可能性があります。 その結果、クエリオプティマイザーが不適切な実行プランを選択し、パフォーマンスが低下することがあります。
一方、WITH FULLSCAN を指定すると、全件スキャンにより統計情報が正確に更新されるため、より適切な実行プランが選ばれやすくなります。
統計情報の重要性を再認識
今回の経験を通じて、統計情報がクエリのパフォーマンスに与える影響の大きさを改めて実感しました。 普段は意識しない部分かもしれませんが、実行プランの精度に直結するため、パフォーマンスチューニングの第一歩として統計情報を確認する習慣を持つのはとても大切です。
運用での工夫ポイント
また、定期的に統計情報を更新するバッチ処理を組み込んだり、更新頻度の高いテーブルだけを対象にしたスクリプトを用意しておくと、本番環境への影響を最小限に抑えつつ安定運用が可能になります。 パフォーマンスの変化に気づいたとき、すぐに試せる手段として UPDATE STATISTICS を覚えておくと安心です。
おわりに
今回は、たまたま FULLSCAN を試したことでクエリのパフォーマンスが改善された事例を紹介しました。 自動更新に頼りきりにならず、状況に応じて手動更新を活用することで、より安定したパフォーマンスを維持できることがあります。
同じような現象に悩んでいる方の参考になれば幸いです。
コメント