几个月前，我们带您了解了微软下一代数据库平台SQL Server Denali的列存储索引功能。针对数据仓库级别的表，它能够在很大程度上改善查询性能。在最新的社区预览版CTP3中，我们有幸接触到列存储索引的完整功能，那么在本文中，我们就将深入了解一下其中的奥秘。

　　同我们熟悉的“行存储”格式不一样，新的架构中每一列索引中的数据都是单独分组并存放的，而列数据是可以被压缩的。此外，当DBA在列存储索引上运行一个查询的时候，SQL Server只读取查询中使用到的列。这样的结果就是：更少的磁盘I/O和更少的内存占用，所以查询的性能将提升数十倍甚至一百倍。

　　对于列存储索引和行存储索引，我们在本文中做了一个对比测试，测试表中包含8500万行数据，笔者使用了不同组合，而得出的结论同微软SQL Server在线指南中的结果完全一致：

• 　　列存储索引往往比行存储索引要快。SQL Server在线指南中提到某些特定的情况下，行存储索引的性能更好，但是大部分情况下毫无疑问是列存储索引;
• 　　同预期的一样，列存储索引在使用聚合以及过滤的查询中效果更佳;
• 　　查询优化器会选择列存储索引比行存储索引速度更快;
• 　　查询执行时间根据不同的应用场景，可能会快上几十倍或者上百倍。列中重复的value越多，那么说明它的压缩率就越高，因此得到的性能提升也更高。同样地，对于数据类型来说也是如此;
• 　　构建一个列存储索引同行存储索引所需要的时间几乎相同。在CTP2版本中，所有的微软MVP试用者都反映列存储索引的构建时间要长一些。但是在CTP3中，微软已经对这一功能进行了改进。

　　考虑一个特殊的场景：一个查询返回结果中有两列，其中value的区别不大;结果集包含850行。使用传统的行存储索引，查询大约花掉了4分钟时间，而使用列存储索引，执行时间降到了1.2秒，速度提升了200倍。此外，测试的Denali Server是一个虚拟机，没有对磁盘I/O进行过优化。

　　妥善使用列存储索引

　　列存储索引并不是完美无暇，它也有自身的限制。每一个表当中只能由一个列存储索引，如果使用表分区，那么你必须在索引中包含分区列。不能包含以下的数据类型：二进制、可变二进制、文本、备注、图像、varchar(max)、nvarchar(max)、唯一标识符、时间戳、精度大于18位的小数和数字、CLR以及XML。

　　除了数据类型限制之外，SQL Server Denali列存储索引中最大的限制是：一旦你创建了一个列存储索引，表就变成只读了，因此任何不能再做任何的数据修改。这对于任何一个更新频繁的表来说都是不太好的消息。

　　微软对此还要做出相应的调整，目前最直接的方法就是只能在预先设置的时间内更新表。删除或者废除索引，然后在更新之后进行重建。

　　或者可以使用分区。使用insert添加一个新的分区，想要更新现有行的时候，再断开，drop列存储索引，更新数据，重现创建索引然后再添加到表中。

　　最后的方法，就是将数据分片成静态数据然后进行更新。保持列存储索引表中的静态数据，然后将需要更新的数据存储在不同的索引表当中。使用UNION ALL语句来从这两种表中进行select。使用这种方法，也能获得部分效果：静态数据表中的列存储索引可以加快查询速度，而另外的传统表格则速度不会提升。

　　当然，这样的情况并不是十分常用，主要适用于数据仓库表或者不经常使用的在线交易处理表等。在SQL Server在线指南中提醒我们慎重使用列存储索引，而这部分功能在未来的正式版中可能会有所改动。所以我们可以推测，在正式版本的SQL Server Denali中，我们将不会受到这样的限制。

　　SQL Server Denali的列存储索引功能在特定环境中的效果十分明显，特别是数据仓库。查询性能上的改进意味着在实际运行中的查询时间将大幅缩短，而我们不需再使用静态数据的聚合表，然后定期刷新了。在使用之前充分考虑公司的具体业务需求，将能达到事半功倍的效果。