小编And*_*lin的帖子

我已经将几个大型表（每个都有 >10^9 行和几十列）从 SQL Server 2014 实例上的聚集行存储移动到聚集列存储索引，并注意到这些表上的统计信息更新（默认采样，在我们的 ETL 中触发）或来自 Hallengren 脚本）现在需要更长的时间。

一个更具理论性的问题是为什么会这样？我的疯狂猜测是，统计信息更新会产生大量随机读取，这与列存储索引不能很好地配合，因为它们更适合大量数据的顺序读取。我很高兴知道更“深入”的解释。

更重要的问题是我是否可以做点什么来反对它。我已经在 SQL Server 2017 实例上尝试了针对具有单个 bigint 列（见下文）的表的测试用例，得到了相同的结果。增量统计在纸面上似乎是一个很好的解决方案。我需要重新创建所有统计对象（目前不是增量的，可能是由于历史原因），扩展 ETL 逻辑并更新我们的 Hallengren 脚本版本（我们目前使用旧版本）。如果有人能在我进入这个兔子洞之前分享他/她的经验，我将不胜感激。

重现步骤：

/*Create a rowstore and a columnstore table with a single bigint column*/
CREATE TABLE dbo.rowstore (col1 BIGINT);
GO

CREATE TABLE dbo.columnstore (col1 BIGINT);
GO

CREATE CLUSTERED COLUMNSTORE INDEX CCI_columnstore ON dbo.columnstore;
GO

/*Fill both tables with 400 * 10^6 rows. This results in a 15GB large rowstore and a 3,1GB large columnstore tables*/
;WITH e1(n) AS …