Azure SQL宽表性能优化：行索引还是列存储索引更适合PBI导入？

问题1：columnStore索引是否是当前场景的最优选择？ #

是，聚集列存储索引（CCI）完全适配你的场景，优势远大于传统行存索引：

• 你的场景属于典型OLAP查询（PBI批量导入数据、仅基于少数列做筛选、宽表查询），列存储按列存储的特性，只会扫描你查询涉及的列，不需要读取350列的全量数据，IO开销远低于行存索引
• 自带的段消除特性可以完美匹配你的筛选逻辑：日期列的每个列存储段都会存储该段的最大/最小日期值，查询近12个月数据时会直接跳过所有不在时间范围内的段，筛选效率远高于行存B树索引
• 列存储索引不会因为增量加载快速失效，适配你每日增量加载的场景

问题2：批次加载2021年数据后是否需要手动刷新索引？ #

不需要强制手动刷新，Azure SQL有自动后台维护机制：

• 单次批量加载的单批次行数大于102400时，数据会直接写入压缩后的列存储行组，不需要额外处理
• 小批量加载（比如你每日5万条增量）的数据会先进入行存格式的增量存储（deltastore），后台的tuple mover进程会自动将符合条件的增量行组压缩为列存储格式，不会影响正常查询
• 如果需要在批次加载完成后立刻最大化查询性能，可以手动执行ALTER INDEX [索引名] ON [表名] REORGANIZE强制压缩所有增量行组，属于非必须操作

问题3：创建列存储索引是否需要包含全部350列？是否会大幅提升存储成本？ #

• 如果你选择最适配当前场景的聚集列存储索引（CCI），默认会包含全表所有列，不需要手动指定包含列
• 列存储的压缩率通常是传统行存结构的3~10倍，哪怕包含全部350列，实际存储占用也远低于原有的行存表/行存索引，不会提升存储成本，反而会降低存储开销
• 如果后续你确定PBI导入只会用到固定的少数列，也可以选择创建非聚集列存储索引，仅包含需要用到的列，存储占用会更低，但灵活性弱于聚集列存储索引

高频率加载超大宽表索引最佳实践 #

• 优先选择聚集列存储索引作为表的主存储结构，替代原有的行存结构，是数据仓库类场景的最优选择
• 增量加载尽量凑成10万行以上的批次再导入，减少小增量行组的产生，降低后台维护压力，同时提升查询性能
• 可以给高频筛选列（Date、Description）额外创建非聚集行存B树索引，进一步加速细粒度筛选的效率，属于可选优化项
• 每次完成大规模批次加载后，可手动执行ALTER INDEX ALL ON [表名] REORGANIZE WITH (COMPRESS_ALL_ROW_GROUPS = ON)清理行组碎片，优化后续查询性能

内容的提问来源于stack exchange，提问作者user2181700