SQL Serverでテーブルごとの統計情報更新日時を確認するSQL

この文書の適用条件

そのまま実行できるコマンド

-- 対象: SQL Server 2008 R2 SP2 / 2012 SP1 以降
-- 権限: 対象DBへの接続権限（sys.stats はメタデータ可視性ルールに従う）
-- 変更作業: なし（参照のみ）
-- Production 実行: 可能
SELECT
    SCHEMA_NAME(o.schema_id)              AS schema_name,
    o.name                                AS table_name,
    s.name                                AS stats_name,
    s.auto_created                        AS is_auto_created,
    STATS_DATE(s.object_id, s.stats_id)   AS last_updated,
    sp.rows                               AS table_rows,
    sp.rows_sampled                       AS rows_sampled,
    sp.modification_counter               AS rows_modified_since_update
FROM sys.stats AS s
INNER JOIN sys.objects AS o
        ON s.object_id = o.object_id
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) AS sp
WHERE o.is_ms_shipped = 0          -- システムオブジェクトを除外
  AND o.type IN ('U', 'V')         -- ユーザーテーブルとビュー
ORDER BY sp.modification_counter DESC, last_updated ASC;

-- 対象: SQL Server 2008（sys.dm_db_stats_properties が使えない環境）
-- 権限: 対象DBへの接続権限
-- 変更作業: なし（参照のみ）
-- Production 実行: 可能
SELECT
    SCHEMA_NAME(o.schema_id)            AS schema_name,
    o.name                              AS table_name,
    s.name                              AS stats_name,
    s.auto_created                      AS is_auto_created,
    s.no_recompute                      AS is_no_recompute,
    STATS_DATE(s.object_id, s.stats_id) AS last_updated
FROM sys.stats AS s
INNER JOIN sys.objects AS o
        ON s.object_id = o.object_id
WHERE o.is_ms_shipped = 0
  AND o.type IN ('U', 'V')
ORDER BY last_updated ASC;

-- 対象: SQL Server 2008 以降
-- 権限: 対象テーブルの所有者 または db_owner / db_ddladmin
-- 変更作業: あり（統計更新 → 該当オブジェクトのプラン再コンパイル）
-- Production 実行: 可能だが I/O とCPUを消費するため時間帯を選ぶこと
UPDATE STATISTICS [dbo].[SampleTable] ([IX_SampleTable_01])
    WITH FULLSCAN;

結果の読み方

こういう状況で使います

• 同じクエリなのに、ある日から急に実行時間が伸びた
• 実行プランの推定行数と実際の行数が大きく食い違う
• 大量のデータ投入・削除を行った直後から特定の処理だけ遅い
• 統計の自動更新に任せているが、実際にいつ更新されたのか分からない

考えられる原因（可能性の高い順）

1. 01

   自動更新のしきい値に達していない

   AUTO_UPDATE_STATISTICS は、変更行数がしきい値を超えたときに次回そのオブジェクトを参照した時点で更新されます。行数の多いテーブルほどしきい値に達しにくく、変更が積み上がったまま古い統計で実行プランが作られることがあります。

2. 02

   サンプリング率が低く、分布が実態とずれている

   既定のサンプリングは全行を読みません。値の偏りが大きい列では、サンプリング結果から推定した行数が実際と乖離することがあります。

3. 03

   統計の自動更新が無効化されている

   データベースオプションの AUTO_UPDATE_STATISTICS が OFF、または個々の統計に NO_RECOMPUTE が設定されていると、明示的に更新するまで古いままになります。

4. 04

   定期メンテナンスジョブが失敗している

   インデックス再構築や統計更新のジョブがエラーで停止していると、更新日時がジョブ停止日で止まります。

確認手順

1. 1

   統計の最終更新日時を一覧化する

   参照のみ

   上記の参照専用SQLを実行し、`last_updated` が古い、または `rows_modified_since_update` が大きい統計を洗い出します。

2. 2

   データベースオプションを確認する

   参照のみ

   `SELECT name, is_auto_update_stats_on, is_auto_create_stats_on, is_auto_update_stats_async_on FROM sys.databases;` で自動更新の設定を確認します。

3. 3

   NO_RECOMPUTE が付いた統計を洗い出す

   参照のみ

   `SELECT name FROM sys.stats WHERE no_recompute = 1;` で自動更新の対象外になっている統計を確認します。

4. 4

   該当クエリの実行プランで推定行数と実行時行数を比較する

   低

   実際の実行プランを取得し、推定行数と実際の行数の差が大きい演算子を特定します。差が小さければ原因は統計ではありません。

対応方法

バージョン・環境による違い

これで解決しない場合に確認すること

• 実行プランの推定行数と実際の行数を比較する

  差が10倍以上ある演算子があるかを確認します。差が無い場合、統計以外（インデックス設計、パラメータスニッフィング、待機事象）を疑います。

• 待機事象を確認する

  CPU 待ちなのか I/O 待ちなのかロック待ちなのかで対処が変わります。CXPACKET が支配的な場合は並列度の確認に進みます。

• パラメータスニッフィングの影響を確認する

  同じクエリでもパラメータ値によって実行時間が大きく変わる場合、統計ではなくプラン再利用の問題である可能性があります。

• メンテナンスジョブの実行履歴を確認する

  `msdb.dbo.sysjobhistory` を参照し、統計更新ジョブが失敗していないかを確認します。

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• SQL Serverで統計情報の最終更新日時を確認したい
• STATS_DATE の使い方が知りたい
• テーブルごとに統計がいつ更新されたか一覧で出したい

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

この確認を一度実行すること自体は難しくありません。しかし、複数のSQL ServerやAurora MySQL環境で継続的に状態を確認し、悪化の兆候が出た時点で対応するには運用体制が必要です。GIIPではAWSとAzure上の複数データベースおよび約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視しています。統計の更新状況のように「一度見れば分かるが、見続けるのが難しい」項目を定常監視に組み込み、変化が出たときだけ人が判断する形にしています。

関連サービス

• データベース性能チューニング
• 24時間監視の対象を確認する