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

[内ヶ島暢之，ユニアデックス株式会社]

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

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

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

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

*1　（関連リンク）統計（SQL Server 2016 and later）（Microsoft TechNet）

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

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

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

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

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

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

筆者紹介

内ヶ島 暢之（うちがしま のぶゆき）

ユニアデックス株式会社 NUL System Services Corporation所属。Microsoft MVP Data Platform（2011〜）。OracleやSQL Serverなど商用データベースの重大障害や大型案件の設計構築、プリセールス、社内外の教育、新技術評価を担当。2016年IoTビジネス開発の担当を経て、2016年現在は米国シリコンバレーにて駐在員として活動中。目標は生きて日本に帰ること。

椎名 武史（しいな たけし）

ユニアデックス株式会社所属。入社以来 SQL Serverの評価／設計／構築／教育などに携わりながらも、主にサポート業務に従事。SQL Serverのトラブル対応で社長賞の表彰を受けた経験も持つ。休日は学生時代の仲間と市民駅伝に参加し、銭湯で汗を流してから飲み会へと流れる。