SQL Server聚集列存储索引的正确维护方法答案

【问题标题】：Correct way of maintenance of SQLServer Cluster Columnstore IndexSQL Server聚集列存储索引的正确维护方法
【发布时间】：2019-07-09 15:24:42
【问题描述】：

集群列存储索引维护

我们在 SqlServer 2016 中为 400M 行使用聚集列存储索引。我们检查示例选择查询的时间——在创建索引后 2 秒。一个月后，相同的查询最多需要 20-30 秒。总碎片为 96% 页面填充度 66%，平均行大小为 20，深度 3。重组索引可减少 1% 的碎片。重建不可用，因为我们需要让所有数据在线。我们每天插入 1M 行。有什么想法吗？

如何获得与初始相似的查询性能？

【问题讨论】：

您是否在测量返回 4 亿行所需的时间？去哪里？通过什么网络？并由什么渲染？我希望随着表变大，返回 4 亿行的查询需要更长的时间（当然比空表要长得多），并且我希望像 SSMS 这样的客户端工具在使用这些行并呈现它们时会越来越困难。如果您的查询没有返回所有数据，并且您需要具体帮助，请提供具体细节 - 表结构（数据类型）、索引定义、查询、实际执行计划。
时间是在创建索引后和一个月后使用相同查询后在 SSMS 中测量的，因为两次尝试数据都相同，因为查询没有改变，问题是（我认为）索引碎片，因为它以前要低得多，所以我需要帮助来减少它

标签： sql-server indexing fragmentation columnstore

【解决方案1】：

有什么想法吗？

问题可能是由于增量存储开销造成的。我们在 SQL Server 2016 上遇到了类似的问题，并且完全重建解决了一段时间。建议：

使用分区，可能每月或每两周一次
在分区级别重建索引，这可以显着减少维护时间。晚上运行重建。
等待 SQL Server 2019，MS 在此版本中在线重建列存储索引

重组索引可减少 1% 的碎片

它是用COMPRESS_ALL_ROW_GROUPS 执行的吗？

ALTER INDEX idx_cci ON table  REORGANIZE WITH (COMPRESS_ALL_ROW_GROUPS = ON); 
ALTER INDEX idx_cci ON table  REORGANIZE;

参考资料：

【讨论】：

是的，我知道重建 Online 将在 2019 年推出，但我们不能等太久才能将其投入生产。我们没有选择在晚上重建索引，因为由于 3 个时区，我们有 24/7 的可用性。从头开始构建该索引需要 13 小时。还尝试使用 compress_all_row_groups 它比没有多提供 1%（因此比运行重组前少 2%）。