データベースの「統計情報」と「パフォーマンス遅延」の関係：SQL Serverトラブルシューティング（40）（2/2 ページ）

「統計情報の更新」とパフォーマンス遅延の関係

　統計情報はテーブルのデータ分布の状況を示します。では、アプリケーションがデータを更新したとき、統計情報はどのように変化するのでしょうか。

　統計情報は通常インデックスを作ったときや明示的に「CREATE STATISTICS」を実行したときに作成されます。この他に、SQL Serverがユーザーアプリケーションからの指令を処理する時点で統計情報を必要とした際に自動作成されます。

　なお、統計情報はレコード更新のたびに更新されるのではなく、既定の動作（*1）では、ある程度レコードの更新量が蓄積されてから自動更新されるようになっています（図2）。

図2　対象とするデータベースのプロパティを確認すると、「統計の自動作成」と「自動更新」が有効（True）になっている

　統計情報の明示的な更新は、「UPDATE STATISTICS」コマンドで行います。UPDATE STATISTICSコマンドでは、全データを基にして統計情報を作成する「FULL SCAN」（図3）、あるいは、前述したようにサンプリングデータを対象とする「SAMPLE」の指定が可能です。SAMPLEでは、サンプリング率を指定することも可能です。

図3　統計情報を「UPDATE STATISTICS」コマンドの「FULL SCAN」指定で更新した例

　統計情報の明示的な更新が必要になるシーンは、「統計情報が実際のテーブルの状況を表していない」と判断できるときです。運用の現場では、自動更新されるタイミングやサンプリングの状況によって、統計情報と実際のデータ分布に乖離（かいり）が生じてしまうことがあります。例えば、「その状況によって、クエリのパフォーマンスが顕著に悪化した」などが挙げられます。

　この場合、筆者の経験では、サンプリング率を指定して更新するよりも、FULL SCANを行ってしまうケースが多いように思います。FULL SCANは大抵の場合、更新にかなりの時間がかかります。しかし、時間がかかるとしても、統計情報をより実態に則したものに更新したい、つまり、この原因に由来するパフォーマンス悪化をきちんと解消したいためというのがその理由でしょう。

　統計情報は、クエリの実行とそれに由来するパフォーマンス遅延のトラブルシューティングをするために重要な概念であることがお分かりいただけたでしょうか。次回は、この統計情報の正しい活用を踏まえた「実行プランのポイント」を解説する予定です。