上一篇
非聚集列存储索引
什么是非聚集列存储索引
非聚集列存储索引是一种以列格式存储数据的索引结构，它不改变表的基础行存储（或聚集列存储）布局，而是作为额外的索引对象存在，该索引专门用于分析型查询（如聚合、扫描、范围过滤），通过高压缩和批处理执行大幅提升I/O效率。
主要特点
- 列式存储：将每列的值连续存储，而非每行整体存储,利于压缩和向量化计算。
- 高压缩率：列内数据相似度高，可达10倍以上压缩，减少存储和I/O。
- 批处理执行：查询引擎使用批处理模式处理列存储数据,加速大表扫描和聚合。
- 非聚集性：不调整表的物理顺序，基础表仍为堆或行存储聚集索引，允许同时存在多个列存储索引（SQL Server 2016+）。
- 可更新性：从SQL Server 2014起，非聚集列存储索引可创建于可更新表上（2016后限制更少），支持INSERT、UPDATE、DELETE,但需维护列存储结构的增量存储段和删除位图。
创建示例（SQL Server）
-在行存储表上创建非聚集列存储索引 CREATE NONCLUSTERED COLUMNSTORE INDEX NCCI_Sales ON SalesOrderDetail (OrderQty, UnitPrice, LineTotal) WHERE OrderQty > 0; -可加过滤条件（SQL Server 2016+）
适用场景
- 数据仓库查询：大表聚合、分组、范围扫描，比行存储索引快10~100倍。
- 混合事务分析处理（HTAP）：在OLTP表上附加列存储索引，同时支持实时交易和高效分析,避免ETL延迟。
- 存储归档：对历史数据使用列存储索引压缩,减少空间占用。
优点
| 优点 | 说明 |
|---|---|
| 查询性能飞跃 | 尤其适合扫描、聚合、星型连接查询 |
| 存储节省 | 压缩率可达10倍以上，降低存储成本 |
| 与行存储共存 | 不破坏基础表原有索引，可逐列调整 |
| 灵活性 | 可创建过滤索引，仅索引部分数据 |
缺点
| 缺点 | 说明 |
|---|---|
| 更新开销 | DML操作需维护列存储增量段和删除位图，频繁写入场景性能下降 |
| 限制条件 | 早期版本（2012~2014）对表结构有较多约束，2016后虽放宽但仍需避免某些特性（如稀疏列、全文索引等） |
| 额外存储 | 列存储索引副本需要额外空间（虽压缩后小于原始行存储，但仍是额外开销） |
| 不适合单行查找 | 点查询性能不如行存储索引，因为列存储需访问所有列段 |
与聚集列存储索引的对比
| 对比项 | 非聚集列存储索引 | 聚集列存储索引 |
|---|---|---|
| 表存储方式 | 基础表仍为行存储堆或B-tree | 表本身以列存储格式存储 |
| 索引数量 | 一个表可创建多个非聚集列存储索引（2016+） | 一个表只能有一个聚集列存储索引 |
| 数据修改 | 对基础表DML，索引自动维护 | 直接修改表，维护代价与列存储结构一致 |
| 压缩率 | 与聚集列存储相当，但基础表行存储未压缩 | 整个表压缩，空间利用更优 |
| 查询性能 | 分析查询快，但需额外维护列存储结构 | 分析查询最快，且无需维护行存储副本 |
| 典型用途 | 在OLTP表上附加分析能力 | 纯分析场景，或HTAP中的主存储 |
与非聚集行存储索引的对比
| 对比项 | 非聚集列存储索引 | 非聚集行存储索引（B-tree） |
|---|---|---|
| 存储格式 | 列式压缩 | 行式，B-tree结构 |
| 查询类型 | 大范围扫描、聚合 | 点查询、区间查找、排序 |
| 更新性能 | 高开销，需维护增量段 | 相对低，但锁开销大 |
| 压缩率 | 高 | 低（可启用数据压缩，但逊于列存储） |
| 索引数量 | 每表多个 | 每表多个（可包含列） |
| SQL Server版本 | 2012+（可更新性从2014起） | 所有版本 |
注意事项
- 版本差异：SQL Server 2012的非聚集列存储索引为只读，2014可更新但限制多，2016+几乎支持所有表类型,且允许过滤索引和聚集列存储上的非聚集列存储索引。
- 维护操作：列存储索引分段过多时，可使用ALTER INDEX REORGANIZE合并增量段,提升查询性能。
- 资源消耗：创建或重建时，需大量CPU和内存,建议在低负载时段执行。
- 外键约束：SQL Server 2016+允许在外键表上创建非聚集列存储索引,但需注意外键操作可能影响维护。
优化建议
- 为频繁聚合的列（如SUM、COUNT）创建非聚集列存储索引。
- 利用过滤索引只索引热点数据,减少存储和维护开销。
- 结合行存储索引：对高选择性查询使用行存储索引,对分析查询使用列存储索引。
- 定期监控索引分段,合并过多小段以提升性能。
相关问题与解答
问题1：非聚集列存储索引与聚集列存储索引的根本区别是什么？生产环境中如何选择？
解答：
根本区别在于是否改变表的物理存储方式，聚集列存储索引直接以列存储格式保存全表数据，表本身就是一个列存储索引；而非聚集列存储索引在行存储表之上附加一个列存储结构
，基础表仍为行存储（堆或B-tree）。
选择建议：
- 如果表主要用于分析查询，且更新频率低（如事实表、历史数据），优先使用聚集列存储索引，可获得最高压缩率和查询性能。
- 如果表同时承载OLTP事务（频繁单行插入、更新）和分析查询（HTAP场景），则保留行存储基础表，并添加非聚集列存储索引，这样事务操作仍由行存储处理，分析查询走列存储索引，避免列存储维护开销影响事务响应。
- 若SQL Server版本低于2014，非聚集列存储索引为只读,需谨慎选择。
问题2：在OLTP表上使用非聚集列存储索引时，哪些操作会导致性能下降？如何缓解？
解答：
主要性能下降来自频繁的DML操作（INSERT、UPDATE、DELETE），因为每次修改都需要将数据写入列存储的增量存储段（delta segment），并维护删除位图，导致：
- 写入放大：单行插入可能需写入多个列段，且后期需要后台合并。
- 查询降级：增量段过多时，查询需扫描多个段，失去列存储优势。
- 锁争用：大并发更新可能引发增量段元数据锁冲突。
缓解方法：
- 批量操作：将单行插入改为批量导入（如BULK INSERT），直接进入列存储段，避免增量段。
- 控制更新频率：对OLTP核心表，仅在非高峰期大量更新，或使用物化列表定期重建列存储索引。
- 定期合并：执行ALTER INDEX REORGANIZE合并增量段，减少段数。
- 使用过滤索引：只索引不常修改的列或行，减小维护范围。
- 版本升级：SQL Server 2016+的列存储索引在更新性能上已有大幅改进,建议使用最新版本。
