Azure SQL の Query Store を管理している場合、2026年6月29日更新の公式ドキュメントでまず押さえるべき点は、Query Store の推奨設定そのものよりも、ALTER DATABASE による設定変更がプランキャッシュを無効化し、直後の再コンパイルによって一時的に性能へ影響する可能性が明記されたことです。Query Store の容量、取得モード、保持期間を見直す作業はこれまで通り重要ですが、本番環境では「いつ変更するか」「変更後にどのクエリを監視するか」まで運用手順に入れる必要があります。Microsoft Learn の対象記事は SQL Server、Azure SQL Database、Azure SQL Managed Instance に適用され、2026年6月29日に更新されています。(Microsoft Learn)
Azure SQL の新機能・変更点：「Best practices for managing the Query Store – SQL Server」で確認すべきポイント
「Best practices for managing the Query Store – SQL Server」は、Query Store を安定して動かすための管理ベストプラクティスをまとめた公式ドキュメントです。Query Store は、クエリ、実行プラン、実行時統計、待機統計などを保持し、プラン変更による性能劣化の調査や、過去の実行状況の確認に使われます。Azure SQL Database と Azure SQL Managed Instance の運用では、障害調査だけでなく、性能監視、チューニング、リリース後の影響確認にも関わるため、設定を放置すると「必要なときに履歴が残っていない」「データが増えすぎて READ_ONLY になっていた」といった問題が起きます。(Microsoft Learn)
今回の更新は、大きな破壊的変更や移行期限の発表ではありません。公開されている更新内容を見る限り、主なポイントは ALTER DATABASE 操作に関する注意喚起の追加です。GitHub の履歴でも、2026年6月29日のコミットは「ALTER DATABASE とプランキャッシュに関する通知を追加」する内容として記録されています。(GitHub)
つまり、Azure SQL 管理者が取るべき対応は「急いで移行する」ことではなく、Query Store の設定変更を通常の軽微な作業として扱わず、性能影響を見込んだ変更管理に組み込むことです。
今回の更新で何が変わったのか
2026年6月29日更新の要点は、Query Store の設定変更を含む多くの ALTER DATABASE 操作について、プランキャッシュへの影響が明記された点です。公式ドキュメントでは、データベースオプション、照合順序、互換性レベル、データベーススコープ構成、ファイルグループ属性などの変更により、対象データベースのプランキャッシュが無効化され、その後のクエリ実行で再コンパイルが必要になり、システム性能に影響する可能性があると説明されています。(Microsoft Learn)
Query Store の文脈では、次のような操作が該当し得ます。
ALTER DATABASE [YourDatabase]
SET QUERY_STORE (
MAX_STORAGE_SIZE_MB = 1024,
QUERY_CAPTURE_MODE = AUTO,
SIZE_BASED_CLEANUP_MODE = AUTO
);このような設定変更は、Query Store の収集方針や容量管理を改善するために有効です。ただし、本番ピーク時間帯に実行すると、直後に多くのクエリが再コンパイルされ、CPU 使用率の上昇や応答時間の一時的な悪化につながる可能性があります。
実務上は、Query Store の設定変更を「監視設定の変更」と軽く見ず、インデックス変更や互換性レベル変更と同じように、変更時間帯、ロールバック方針、変更後の監視項目を決めてから実施するのが安全です。
影響範囲：Azure SQL Database と Azure SQL Managed Instance のどこに関係するか
対象範囲は、SQL Server、Azure SQL Database、Azure SQL Managed Instance です。Azure SQL を利用している場合、特に影響が大きいのは Azure SQL Database の単一データベース、エラスティックプール、Azure SQL Managed Instance で Query Store を性能監視に使っている環境です。(Microsoft Learn)
| 対象 | 影響の見方 | 管理者が確認すべきこと |
|---|---|---|
| Azure SQL Database 単一データベース | Query Store は新規データベースで既定有効。無効化できない点に注意 | 容量上限、取得モード、保持期間、READ_ONLY 化の有無 |
| Azure SQL Database エラスティックプール | 複数DBで Query Store データが増え、DBごとの容量管理が課題になりやすい | プール内の高負荷DB、アドホッククエリの多いDB、容量逼迫DB |
| Azure SQL Managed Instance | SQL Server に近い運用設計が必要 | 既存設定、収集対象、待機統計、メンテナンス手順 |
| グローバル展開DB | リージョンごとに負荷時間帯が異なる | 設定変更の実施時間、変更後の監視窓、業務影響の有無 |
Azure SQL Database の単一データベースとエラスティックプールでは、ALTER DATABASE [database] SET QUERY_STORE = OFF を実行しても、Query Store を無効化できないことが公式ドキュメントで説明されています。したがって、Azure SQL Database では「無効化して逃げる」のではなく、QUERY_CAPTURE_MODE、MAX_STORAGE_SIZE_MB、STALE_QUERY_THRESHOLD_DAYS、SIZE_BASED_CLEANUP_MODE を適切に調整して、収集を継続できる状態に保つことが基本になります。(Microsoft Learn)
管理者がまず確認すべき Query Store の状態
Azure SQL の Query Store 管理で最初に確認すべきなのは、Query Store が実際に READ_WRITE で動作しているかです。設定上は有効でも、容量上限に達して READ_ONLY になっていると、新しい実行情報が収集されません。その状態で性能劣化が起きると、調査に必要な履歴が欠けてしまいます。
まず、対象データベースに接続して次の T-SQL を実行します。
SELECT
actual_state_desc,
desired_state_desc,
current_storage_size_mb,
max_storage_size_mb,
readonly_reason
FROM sys.database_query_store_options;見るべきポイントは、actual_state_desc、current_storage_size_mb、max_storage_size_mb、readonly_reason です。公式ドキュメントでは、Query Store のサイズが上限に達すると READ_ONLY に切り替わり、新しいデータ収集が止まると説明されています。(Microsoft Learn)
| 確認項目 | 問題の例 | 対応の考え方 |
|---|---|---|
actual_state_desc | READ_ONLY になっている | 容量上限、クリーンアップ設定、取得モードを確認 |
desired_state_desc | 期待値と実状態が違う | readonly_reason を確認し原因を特定 |
current_storage_size_mb | 上限に近い | 保持期間短縮、取得モード見直し、容量拡張を検討 |
max_storage_size_mb | 小さすぎる | 高負荷DBでは拡張。ただし取得ポリシー見直しを優先 |
readonly_reason | サイズ上限などの理由が入る | 一時的な状態か、恒常的な設計不備かを判断 |
readonly_reason は、Query Store が READ_ONLY になった理由を判断するための重要な列です。たとえば、サイズ上限に達した場合は max_storage_size_mb に関連する理由が返されます。(Microsoft Learn)
Azure SQL Database の既定値で押さえるべき設定
Azure SQL Database では、Query Store が継続的にデータを収集できるように既定値が最適化されています。公式ドキュメントでは、MAX_STORAGE_SIZE_MB、INTERVAL_LENGTH_MINUTES、STALE_QUERY_THRESHOLD_DAYS、SIZE_BASED_CLEANUP_MODE、QUERY_CAPTURE_MODE、DATA_FLUSH_INTERVAL_SECONDS などの既定値が整理されています。(Microsoft Learn)
実務で特に重要なのは、次の5つです。
| 設定 | 既定・推奨の考え方 | 実務での判断基準 |
|---|---|---|
QUERY_CAPTURE_MODE | Azure SQL Database では AUTO が基本 | アドホッククエリが多い環境では ALL を避ける |
MAX_STORAGE_SIZE_MB | SQL Server 2019 以降相当では 1000MB が既定値の目安 | 高負荷DBでは不足しないか定期確認 |
STALE_QUERY_THRESHOLD_DAYS | Azure SQL Database の既定は 30日 | 調査に必要な期間だけ保持する |
SIZE_BASED_CLEANUP_MODE | AUTO が基本 | READ_ONLY 化を避けるため有効化を維持 |
DATA_FLUSH_INTERVAL_SECONDS | 900秒、つまり15分が既定 | 障害時のデータ損失許容度とI/O影響で調整 |
ポイントは、容量を増やす前に「不要なクエリを取りすぎていないか」を確認することです。MAX_STORAGE_SIZE_MB を増やせば一時的に空きはできますが、アドホッククエリや一度だけ実行されるクエリを大量に収集している環境では、根本的な解決になりません。
Query Store Capture Mode は原則 AUTO、例外的に CUSTOM を検討する
Query Store Capture Mode は、どのクエリを Query Store に記録するかを決める設定です。公式ドキュメントでは、ALL、AUTO、NONE、CUSTOM の使い分けが示されています。SQL Server 2019 以降では AUTO が既定であり、Azure SQL Database でも関連性の高いクエリに絞る設定として重要です。(Microsoft Learn)
| Capture Mode | 向いているケース | 注意点 |
|---|---|---|
ALL | 全クエリを詳細に分析したい短期調査 | アドホッククエリが多いと容量を圧迫しやすい |
AUTO | 通常運用、継続監視 | 頻度や負荷の小さいクエリは収集対象外になる場合がある |
NONE | すでに必要なクエリを収集済みの検証環境 | 新しい問題クエリを見逃す可能性がある |
CUSTOM | 大規模DB、ユニークなアドホッククエリが多いDB、容量制約が厳しいDB | しきい値設計を誤ると重要クエリを取り逃がす |
多くの本番環境では、まず AUTO を選びます。CUSTOM は、Query Store の容量増加が速すぎる、アドホッククエリが多すぎる、または保持期間を維持したまま収集対象を絞りたい場合に検討します。
たとえば、公式ドキュメントでは次のような CUSTOM 設定例が示されています。(Microsoft Learn)
ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE = ON
(
OPERATION_MODE = READ_WRITE,
CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 90),
DATA_FLUSH_INTERVAL_SECONDS = 900,
MAX_STORAGE_SIZE_MB = 1000,
INTERVAL_LENGTH_MINUTES = 60,
SIZE_BASED_CLEANUP_MODE = AUTO,
QUERY_CAPTURE_MODE = CUSTOM,
QUERY_CAPTURE_POLICY = (
STALE_CAPTURE_POLICY_THRESHOLD = 24 HOURS,
EXECUTION_COUNT = 30,
TOTAL_COMPILE_CPU_TIME_MS = 1000,
TOTAL_EXECUTION_CPU_TIME_MS = 100
)
);ただし、いきなり本番で厳しいしきい値に変更するのは避けるべきです。公式ドキュメントでも、Query Store のディスク使用量を減らすために値を調整する場合は、小さな増分で段階的に変更することが推奨されています。(Microsoft Learn)
実務では、次の流れが安全です。
| 手順 | 作業 | 判断基準 |
|---|---|---|
| 事前確認 | 現在の Query Store サイズと READ_ONLY 化の有無を確認 | 上限の80％前後に近づいていないか |
| 短期観察 | 上位クエリ、アドホッククエリ、プラン数を確認 | 一度だけのクエリが容量を圧迫していないか |
| 変更案作成 | AUTO 維持か CUSTOM 化かを決める | 重要クエリを取り逃がさない条件か |
| 本番変更 | ピーク時間を避けて ALTER DATABASE を実行 | 再コンパイルによるCPU上昇を許容できる時間帯か |
| 変更後監視 | CPU、Duration、Query Store サイズ、actual_state_desc を確認 | 収集継続と性能影響の両方を見る |
MAX_STORAGE_SIZE_MB は「増やせばよい」ではない
Query Store の最大サイズは、Query Store が使用できるデータベース内の領域上限です。上限に達すると Query Store が READ_ONLY になり、新しいデータを収集できなくなります。Azure SQL Database では MAX_STORAGE_SIZE_MB の最大許容値が 10,240MB とされています。(Microsoft Learn)
容量不足が起きた場合、次のように上限を変更できます。
ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (MAX_STORAGE_SIZE_MB = 2048);ただし、容量拡張だけで解決しないケースもあります。たとえば、ORM がリテラル値を埋め込んだSQLを大量に発行している場合、Query Store には似た形のアドホッククエリが大量に蓄積されます。この状態で上限だけを増やしても、数日後に再び上限へ近づく可能性があります。
判断基準は次の通りです。
| 状況 | 優先すべき対応 |
|---|---|
| 重要な本番DBで調査履歴が不足している | 一時的に MAX_STORAGE_SIZE_MB を増やす |
| アドホッククエリが多い | QUERY_CAPTURE_MODE = AUTO または CUSTOM を検討 |
| 古い履歴をほとんど使っていない | STALE_QUERY_THRESHOLD_DAYS を短縮 |
| サイズ上限に近づく頻度が高い | 取得対象、保持期間、アプリ側SQL生成を見直す |
| 一時的なリリース調査だけ必要 | 期間限定で設定を広げ、後で戻す |
Query Store は性能トラブル時の「ドライブレコーダー」のような存在です。容量が小さすぎると必要な映像が残らず、広げすぎると不要な映像ばかり保存して管理しづらくなります。
保持期間とクリーンアップ設定は運用目的から逆算する
STALE_QUERY_THRESHOLD_DAYS は、Query Store に保持する古い実行統計や非アクティブなクエリの保持期間を制御します。公式ドキュメントでは、Azure SQL Database の既定として 30日が示され、不要な履歴を保持しすぎないことが推奨されています。(Microsoft Learn)
たとえば、次のように保持期間を設定できます。
ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (
CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 30)
);保持期間は長ければ良いわけではありません。月次バッチの調査が必要なら30日以上の履歴が役立つことがありますが、日次運用の性能監視が中心なら14日程度でも十分な場合があります。逆に、週次や月次でしか発生しない処理があるのに保持期間を短くしすぎると、比較対象が消えてしまいます。
| 運用目的 | 保持期間の考え方 |
|---|---|
| 日々の性能劣化検知 | 7〜14日程度でも運用可能な場合がある |
| リリース前後の比較 | リリース周期をまたげる期間を確保 |
| 月次処理の調査 | 30日以上を検討 |
| 長期トレンド分析 | Query Store だけに頼らず、別の監視基盤への集約も検討 |
| 容量逼迫の回避 | 保持期間短縮と取得モード見直しをセットで行う |
SIZE_BASED_CLEANUP_MODE = AUTO も重要です。この設定により、Query Store のサイズが上限に近づいたときに自動クリーンアップが行われます。ただし、高負荷環境では自動クリーンアップが追いつかず、一時的に READ_ONLY へ切り替わる可能性があります。(Microsoft Learn)
DATA_FLUSH_INTERVAL_SECONDS は障害時のデータ損失とI/O負荷のバランスで決める
DATA_FLUSH_INTERVAL_SECONDS は、Query Store がメモリ上に保持している実行時統計をディスクへ永続化する間隔です。公式ドキュメントでは、既定値は900秒、つまり15分とされています。(Microsoft Learn)
この値を長くすると、書き込み頻度を下げられる一方で、ディスクへの書き込みが一度に重くなる可能性があります。また、フェールオーバーやシャットダウン時に、永続化前の情報が失われるリスクも大きくなります。
一方で、短くすると永続化の頻度が上がり、障害時に失われる可能性があるデータは減りますが、I/O がより頻繁に発生します。
| 設定方針 | メリット | 注意点 |
|---|---|---|
| 間隔を長くする | Query Store の書き込み頻度を抑えられる | 障害時に未保存データが増える可能性 |
| 既定値の900秒を維持 | 多くの環境でバランスが良い | 特殊な高負荷環境では観察が必要 |
| 間隔を短くする | 障害時に失う統計を減らしやすい | 書き込み回数が増える |
Azure SQL の通常運用では、まず既定値を維持し、実際のI/O負荷やフェールオーバー後の調査要件を見て調整するのが現実的です。
ALTER DATABASE 実行時の注意点：今回の更新で最も重要な実務ポイント
今回の更新で特に重要なのは、Query Store の設定変更に使う ALTER DATABASE 操作が、プランキャッシュへ影響する可能性を持つ点です。公式ドキュメントでは、多くの ALTER DATABASE 操作が対象データベースのプランキャッシュを無効化し、その後の実行で再コンパイルが必要になり、性能に影響する可能性があると説明されています。(Microsoft Learn)
本番環境では、次のような変更でも注意が必要です。
ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (
QUERY_CAPTURE_MODE = AUTO,
SIZE_BASED_CLEANUP_MODE = AUTO,
MAX_STORAGE_SIZE_MB = 2048
);この変更自体は Query Store の健全性を高めるためのものですが、実行直後に再コンパイルが集中すれば、短時間のCPU上昇やレスポンス悪化が起きる可能性があります。
特に注意したいのは、次のような環境です。
| 環境 | リスク |
|---|---|
| 高頻度OLTP | 再コンパイルが集中し、CPU使用率が一時的に上がる |
| グローバル利用のSaaS | 地域ごとにピーク時間が異なり、変更時間の選定が難しい |
| リリース直後のDB | アプリ変更とQuery Store変更の影響切り分けが難しくなる |
| CPU余力が少ないDB | 軽微な再コンパイルでも性能問題として表面化しやすい |
| 自動スケールやサーバーレス構成 | 変更直後の負荷変動を通常負荷と誤認しやすい |
安全に変更するなら、少なくとも次の項目を手順書に入れておきます。
| タイミング | 確認すること |
|---|---|
| 変更前 | sys.database_query_store_options、CPU使用率、上位クエリ、現在のDB負荷 |
| 変更中 | 実行する ALTER DATABASE 文、対象DB、実行者、実行時刻 |
| 変更直後 | CPU、Duration、コンパイル増加、Query Store の actual_state_desc |
| 変更後数時間 | Query Store サイズ増加率、READ_ONLY 化の有無、上位待機 |
| 翌営業日 | 業務影響、アラート発生有無、設定値の妥当性 |
移行期限や強制変更はあるのか
2026年6月29日更新の公式情報を見る限り、今回の「Best practices for managing the Query Store – SQL Server」更新に伴う移行期限、廃止期限、強制的な設定変更期限は示されていません。更新の中心は、Query Store 管理に関するベストプラクティスと、ALTER DATABASE 操作時の注意喚起です。(Microsoft Learn)
そのため、管理者が今すぐ行うべきことは、期限対応ではなく棚卸しです。
具体的には、次の3点を確認します。
- Query Store が
READ_WRITEで動作しているか - 容量上限に近づいていないか
- Query Store 設定変更の手順に、プランキャッシュ無効化後の監視が含まれているか
期限がないからといって放置してよいわけではありません。Query Store は性能障害が起きた後に設定を見直しても、過去データが残っていなければ十分に役立ちません。平常時に収集状態を整えておくことが、障害対応時間の短縮につながります。
失敗しやすいポイントと回避策
Azure SQL の Query Store 管理で失敗しやすいのは、設定値を単独で見てしまうことです。たとえば、MAX_STORAGE_SIZE_MB が大きくても、QUERY_CAPTURE_MODE = ALL で不要なアドホッククエリを大量に取っていれば、いずれ容量問題が再発します。逆に、CUSTOM で絞りすぎると、障害時に必要なクエリが残っていない可能性があります。
| 失敗例 | 起きる問題 | 回避策 |
|---|---|---|
| 容量不足時に上限だけ増やす | 数日後に再び容量逼迫 | 取得モードと保持期間も同時に見直す |
ALL を常時利用する | アドホッククエリで肥大化 | 通常運用は AUTO を基本にする |
NONE を本番で使い続ける | 新規問題クエリを追えない | 限定的な検証用途にとどめる |
| 設定変更をピーク時に実行 | 再コンパイルで一時的に性能悪化 | メンテナンス時間帯に実施する |
| Query Store の状態を監視していない | READ_ONLY 化に気づかない | 定期的に sys.database_query_store_options を確認 |
| 保持期間を長くしすぎる | 不要データで容量を圧迫 | 調査に必要な期間から逆算する |
特にグローバル向けサービスでは、日本時間の夜間が他地域のピークである場合があります。設定変更の実施時間は、単一リージョンの業務時間だけでなく、実際のトラフィック分布を見て判断する必要があります。
実務で使える確認用 T-SQL
最後に、Azure SQL 管理者がすぐ使える確認用 T-SQL をまとめます。
Query Store の現在状態を確認する
SELECT
actual_state_desc,
desired_state_desc,
current_storage_size_mb,
max_storage_size_mb,
readonly_reason,
query_capture_mode_desc,
size_based_cleanup_mode_desc,
stale_query_threshold_days,
interval_length_minutes,
flush_interval_seconds
FROM sys.database_query_store_options;actual_state_desc が READ_WRITE で、current_storage_size_mb が max_storage_size_mb に近づきすぎていないかを確認します。
Query Store の容量上限を変更する
ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (
MAX_STORAGE_SIZE_MB = 2048
);実行前に、容量不足の原因が「保持期間」なのか「取得対象の多さ」なのかを確認してください。
Query Capture Mode を AUTO にする
ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (
QUERY_CAPTURE_MODE = AUTO
);通常運用では、関連性の高いクエリを中心に収集する AUTO が扱いやすい選択肢です。
サイズベースの自動クリーンアップを有効にする
ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (
SIZE_BASED_CLEANUP_MODE = AUTO
);Query Store が容量上限に近づいたときの自動クリーンアップに関わるため、継続収集を重視する環境では確認しておきたい設定です。
保持期間を調整する
ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (
CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 30)
);保持期間は、リリース周期、月次処理、障害調査の要件から逆算して決めます。
管理者が次に取るべき行動
今回の更新ポイントは、Query Store の新機能追加というより、Query Store 設定変更を安全に運用するための注意点が強化されたことです。特に ALTER DATABASE による設定変更では、プランキャッシュ無効化と再コンパイルの影響を考慮する必要があります。
Azure SQL 管理者は、まず対象データベースごとに Query Store の状態を確認してください。READ_ONLY になっていないか、容量が上限に近づいていないか、QUERY_CAPTURE_MODE が運用目的に合っているかを見直します。そのうえで、設定変更が必要な場合は、ピーク時間を避け、変更後のCPU、Duration、Query Store サイズ、actual_state_desc を監視する手順まで整えてから実行するのが安全です。
Query Store は、問題が起きてから有効化するものではなく、問題が起きる前から適切に動かしておくべき性能調査基盤です。今回の公式情報をきっかけに、Query Store の設定値だけでなく、変更管理と監視手順まで含めて見直しておきましょう。
コメント