浅谈MSSQL2012中的列存储索引（columnstore indexes）

列存储索引为MSSQL2012版本中引进的一个新特性。所有版本MSSQL中标准查询处理模式采用一次一行模型，操作符每次处理一行数据。列存储索引中增加了一种新的基于向量的查询执行功能，通过这种功能，操作符可以一次处理一批（多行）数据。这样，除了可以改善IO性能外，该功能也可以在其他方面带来好处。因为，列存储索引被做了压缩处理，并且，典型数据仓库场景的查询只会用到表列数的10~15%（这样，就可以节省大部分的不必要的磁盘IO）。通过减少数据在操作附件的移动及优化的新处理算法而对性能，批处理数据又可以使查询性能受益。同时，段消除的采用也会使查询性能大大改善。
列存储索引对数据仓库场景具备很大优势，然而，它并打算取代最适合OLTP场景的行存储和处理。查询优化器将自动决定何时用列存储索引，何时用用其他类型的数据存取方式（B-Tree或堆）。查询优化器也将根据具体情况选择处理模式，例如：处理大量数据的查询采用批处理模式，而OLTP业务采用行处理模式。只有当列存储索引可用时，批处理模式才可能被采用。执行计划中也可能既包括批处理模式的操作符，也包括行处理模式的操作符，但成本高的部分应该采用批处理模式，这也可以作为我们排查查询性能问题的一个因素。
以下几个操作符既能运行在行处理模式也能运行在批处理模式：hash join, hash aggregate, project，filter及columnstore index scan。而新操作符 batch hash table build只能运行在批处理模式。批处理操作符需要输入为一批数据行，而行处理模式则要求一行数据。执行计划能包括一组批处理操作符和行处理操作符，但查询处理器将尽力减少它们之间转换的次数，因为批处理模式和行处理模式数据格式间的转换会导致性能问题。包含批处理操作符的执行计划也能利用优化位图过滤，这将会把谓词下推到存储引擎，从而实现尽早将过滤掉无用数据。与B-Tree索引不同，列存储索引没有相关统计数据被收集，优化器将会依据基表的统计数据做出判断。
当系统没有足够的内存或线程可用时，一个执行计划可能会从批处理模式切换到行处理模式，有时，这也可能会导致性能问题。你可以通过查看执行计划及比较评估和实际执行模式或通过扩展事件（batch_hash_table_build_bailout）来进行判断。内存问题是最常见的原因，因为被批处理模式使用的哈希表需要被放到内存中， 如果运行过程中内存不足，MSSQL将会动态的切换回行处理模式。内存不足可能由不精确的基数评估引起，这样，你也许需要确认和更改相关表的统计信息。然而，一个评估的并行执行计划切换回串行可能表示系统线程不足。
列存储索引最明显的劣势，至少在MSSQL2012版本是这样，将来的版本中也许会消失，那就是存在列出存储索引的表不可修改，这可以通过如下三个方法来克服：
1） 删除/重建列存储索引；
2） 用分区切换技术；
3） 用union all语法；