小编rus*_*ind的帖子

我们有一些数据库有宽表COLUMNSTORE压缩（21 或 30 COLUMNS）和 2500 个分区（按日期）。该数据库中大约有 4000 个 stats 对象，其中大部分是分区表上的 INCREMENTAL 列统计信息。

sys.dm_db_stats_properties在这些数据库上运行时，这个表函数的性能极差。我们正在查看每行大约 1 秒 - 即此表函数的每次“运行”。

下面是一个简单查询生成的查询计划示例，其CROSS APPLY语法用于针对 1605 个 stats-table 组合执行此表函数。

这里没有什么非常有帮助的 - DMV 的表现显然很差。

我目前的理论是，由于数据库中统计对象的性质，对 OPENROWSET 内部表的查询优化不佳（可能是TOP 1，这就是导致速度变慢的原因。

CREATE FUNCTION sys.dm_db_stats_properties (@object_id int, @stats_id int)
RETURNS TABLE
AS
RETURN SELECT TOP 1 -- The first row in the TVF will be the root; avoid scanning entire TVF to find any additional rows.
    object_id, -- Columns now explicit since underlying tvf …

我正在查看SQL Server 标准版和企业版之间的差异，但无法重现此演示中宣传的差异，以解释这些差异- 我在跨标准版和企业版运行查询时观察到的性能具有可比性，并且查询并行运行执行计划中的分区表。

我已经证实：

• 查询产生相同的查询计划
• 查询产生类似的运行时 set statistics time on

似乎在 SQL Server 2016 中，这种差异是不可重现的。此功能是否还有其他影响 - 也许我没有测试正确的东西，但查询与演示中的查询相当。

这是我用来测试的脚本：

-- MAXDOP is 10

--  structure of table
--Column                type
--testData.PKcolumn1    bigint
--testData.PKcolumn2    int
--date                  datetime
--testData.PKcolumn3    bigint
--metric1               float
--metric2               float
--metric3               float
--metric4               float

--index_description                                                 index_keys
--clustered, unique, primary key located on ps_testData             categoryId, transactionId, date

--pf_testData/ps_testData is a range right datetime partition scheme,  fanout 368
GO

-- Actual partition count: …