Top Answer: [LowlyDBA's answer] covers what the metrics actually *mean.* This answer is just to explain why the numbers in the Query Store user interface don't totally make sense.
Answer #2: If we look at the documentation for the underlying object, [`sys.query_store_runtime_stats`](https://docs.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-query-store-runtime-stats-transact-sql?view=sql-server-2017), we'll see it has the following descriptions:
Top Answer: I see this on my SQL Server 2016 instance as well (same settings as yours: 15 min data flush, and 1 hour stats collection). I noticed that the plans with missing information correlated with AG failovers and maintenance-related reboots (which I found by looking in the SQL Server error log).
Top Answer: First of all, you might be able to get acceptable performance with queries directly against the query store catalog views by updating stats, adding query hints with plan guides, or changing the database compatibility level / CE. See the answers from Forrest and Marian here:
Answer #2: As a supplement to the [great answer by Josh Darnell](https://dba.stackexchange.com/a/231658/21924) I read through all the descriptions of the data views that are being exported into tables. The following code adds the primary keys, clustered indexes and foreign keys as described in the Microsoft documents. It should help with queries against the data.
Top Answer: @SqlWorldWide answered the "why `[msdb]`" part of the question so I won't duplicate that here. But to answer the "why not `[master]`, `[model]`, `[tempdb]`" part of the question:
Top Answer: > Is blockchain a **potentially viable database** solution for modern, **high transaction volume** applications?
Answer #2: I'm very familiar with cryptocurrency and databases, and I can tell you it's not a great DB engine at all.
Answer #3: In 2014 we built ascribe.io with the premise of using Bitcoin as a database for Intellectual Property claims. Upon release, we plugged the network because it couldn't handle the throughput, latency was at least 10 minutes and we were limited by what we could put into the OP_RETURN, forcing us to store the actual digital file relating to the claim in Amazon S3. We realized that Bitcoin in its current form could never be a high transaction database.