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

「統計情報」とは何か

　SQL Serverにおける統計情報とは、「テーブルやインデックス内で、どんな値が、どんな頻度で出現するのかをまとめた情報」のことを指します。この情報から、データベース内では「どんなレコード操作を行えば効率的に処理を実行できるか」を、統計学の考え方を用いて推定しています。

　例えば、あるテーブルで作成される統計情報は、既定動作では“全データを対象”とした分布までは作りません。効率を考慮して、統計学的に十分とされる、ある程度間引いた（サンプリングした）データから分布情報を作ります。統計情報は、「DBCC SHOW_STATISTICS」コマンド、または「SSMS（SQL Server Management Studio）」で表示できます（図1）。

図1　統計情報の内容を確認したところ

　図1では、「TABLE1」というテーブルに存在する「PK__BigTable__3213E83F438B8414」という名前の統計情報の内容を「DBCC SHOW_STATISTICS」コマンドで確認しています。

　確認している「PK__」から始まる統計情報は、テーブルに主キーを設定したときに自動的に作られた統計情報です。PKはPrimary Keyの略です。統計情報の出力は3パートに分かれています。最初は「統計情報全体」のプロパティ、2つ目は「密度や平均長、列名の情報」、3つ目は「実際に統計に含まれるヒストグラム情報」が出力されます。ヒストグラムとは、ある範囲に値が幾つあったのかを表した度数分布の値のことです。

　あらためて図1の結果からは、「100万行」あるテーブルのうち、「23万6844行」を参照して統計情報が作られていること、そして、列の平均長は「8バイト」であることなどを確認できます。

　もっとも、トラブルシューティングのためにこの情報を参照することはめったにないかもしれません。しかし、統計情報の原理を理解していることで、起きている現象を正しく把握できることもあります。この機会に、「こうなっている」ことを理解しておいてください。

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

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

　統計情報は通常インデックスを作ったときや明示的に「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は大抵の場合、更新にかなりの時間がかかります。しかし、時間がかかるとしても、統計情報をより実態に則したものに更新したい、つまり、この原因に由来するパフォーマンス悪化をきちんと解消したいためというのがその理由でしょう。

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