1 [LowlyDBA's answer](https://topanswers.xyz/databases?q=860#a1016) 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.
1 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:
0 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.
8 Excellent question. As far as I am aware of, under those conditions (i.e. guaranteed no `NULL`s and no need for the extra functionality) there shouldn't be any specific concerns. This could be a situation similar to `CURSOR`s where, if a generic rule is needed, it would be: "don't use cursors". But, the actual rule is: "only use cursors when/where appropriate". The problem is educating people on the technical details of cursors such that they can make that decision, which is those of us who know enough about such things ignore the generic rule and proceed to use them appropriately.
5 The normal short-term solution here is to simply [move some indexes and tables to the new filegroup](https://docs.microsoft.com/en-us/sql/relational-databases/indexes/move-an-existing-index-to-a-different-filegroup?view=sql-server-ver15) to free up space in the primary filegroup.