msdbでクエリストアを有効にするとどのようなメリットがありますか？

SQLシステムデータベース（master、model、msdb、tempdb）のクエリストアは、msdbでのみ使用できます。msdbのクエリストアに関するドキュメントを探しましたが見つかりませんでした。

GUIには表示されませんが、SQL 2016インスタンスで検証できます

クエリストアの検証がオフです

USE msdb
SELECT * FROM sys.database_query_store_options; 

クエリストアをオンにする

USE [master]
GO
ALTER DATABASE msdb SET QUERY_STORE = ON
GO
ALTER DATABASE msdb SET QUERY_STORE (OPERATION_MODE = READ_WRITE
, INTERVAL_LENGTH_MINUTES = 30
, MAX_STORAGE_SIZE_MB = 1000
, QUERY_CAPTURE_MODE = AUTO)
GO

クエリストアの検証がオンになっています

USE msdb
SELECT * FROM sys.database_query_store_options; 

すべてのシステムデータベースの中で、msdbがクエリストアを使用するオプションを持つ唯一のデータベースである理由と、それによって追加される値は何ですか。

-- Stop Query Store
USE [master]
GO
ALTER DATABASE msdb SET QUERY_STORE = OFF
GO

Microsoftが機能を有効にしても、それがすべての人に役立つとは限りません。一部の機能を使用するシステムでは、MSDBに格納されている情報に依存することを意味します。このような場合、クエリストアが役立ちます。

ここでは、MSDBデータベースオブジェクトの使用とチューニングに関する記事をいくつか紹介します。

オンラインブックのmsdbデータベース。

MSDBパフォーマンスチューニング（Geoff N. Hiten著）

Tim Radney によるMSDBのメンテナンスの重要性

msdbのインデックスの最適化は、ユーザーデータベースと同じくらい重要です。多くの場合、ユーザーデータベースを最適化しているが、システムデータベースは最適化していないクライアントを見つけました。msdbデータベースは、SQL Serverエージェント、ログ配布、Service Broker、SSIS、バックアップと復元、およびその他のプロセスによって頻繁に使用されるため、インデックスが非常に断片化する可能性があります。インデックス最適化ジョブにシステムデータベース、または少なくともmsdbが含まれていることを確認してください。インデックスの最適化により、msdb内の非常に断片化されたインデックスから数ギガバイトのスペースが解放されるのを見てきました。

クエリストアが、インデックス作成戦略を最適化し、MSDBに格納されている情報の一部を最適にクエリ/集約/パージするのにどのように役立つかがわかります。

@SqlWorldWideは質問の「なぜ[msdb]」の部分に回答したので、ここではそれを複製しません。しかし、答えるために「なぜ[master]、[model]、[tempdb]」質問の一部：

• [tempdb]は一時的なストレージであり、その性質上、自動最適化または履歴分析を提供する機能のどちらからも恩恵を受けることはないようです。クエリストアがストアドプロシージャの実行統計を追跡する場合、ストアドプロシージャが他の場所に存在する場合、ここでは役に立ちません。一時的なストアドプロシージャを作成することは可能ですが、ローカルの一時的なストアドプロシージャの名前には、複数のセッション間で同様の名前を分離するための一意のハッシュコードが含まれているため、これによるメリットはおそらくありません。また、一時的な性質を考えると、グローバル一時Stored Procはセッション間で一貫した名前を持っていますが、セッション全体で同じ名前のグローバル一時Stored Procが同じコードであると仮定する方法はありません。したがって、意味のある /相関可能な統計。

• [model]新しいデータベースを作成するためのテンプレートです（[tempdb]SQL Serverインスタンスが起動/再起動するたびに再作成されるを含む）。ここからクエリは実行されません。ただし、ここでクエリストアを有効にして、新しいDBを作成するときにデフォルトでオンになるようにしてもかまいません。しかし、しかしにそのしかし、そのクエリストアを意味するだろうがで有効にされるだろう[tempdb]し、それは愚かな（直接上記の点を参照）です。

  更新：
  うわー、ネリー！これにつながる最初の質問をもう一度読んだところ、奇妙なことに気づきました。エラーメッセージは[master]とだけ[tempdb]でした。のエラーは報告されていません[model]。OPが質問にコピーするときにそのエラーメッセージを単に省略した可能性があるため、SQL Server 2016 SP1-CU7-GDR（13.0.4466.4）で次のコマンドを実行して確認しました。

  ALTER DATABASE [model] SET QUERY_STORE = ON; -- completes successfully!
  
  -- Restart instance to force recreation of [tempdb];
  
  CREATE DATABASE [IsQueryStoreEnabledByDefault];
  
  SELECT * FROM sys.databases WHERE [is_query_store_on] = 1;
  
  DROP DATABASE [IsQueryStoreEnabledByDefault];

  そして結果は？[model]そして、[IsQueryStoreEnabledByDefault]返されますが、[tempdb]あるではない結果に！だから、追加しかし最初の二つの「しかし」sまで、それはそう[model] することができます（はい、それは言葉だ、私も新たに作成したDBを、Bの;-)にチェック）クエリStoreがある）デフォルトクエリストアド有効化を有効にしています[tempdb]サービス開始時の再作成では無視されます（したがって、これはでサービスをオンにするためのバックドアではありません[tempdb]）。  

• [master]メインシステムデータベースであり、ここでコードを実行しないでください。また、ここに存在し、頻繁に使用されるストアドプロシージャは、最適化の恩恵を受けないか、それらが呼び出されるユーザーデータベースのコンテキストで実行されます（つまりsp_、で始まるシステムストアドプロシージャは、すべてに表示される特殊なケースです） DB —で完全に修飾する必要はなく[master]..、実際に各DBに存在するかのように実行します）、DBは、呼び出されているユーザーデータベースのクエリストアによって管理されている可能性があります。