如果你是一个资深的SQL Server DBA，那么关于它的每一个功能你应该都会接触过至少一次。事实上，SQL Server发展到现在，它的根基并没有变，一个大树上长出纷繁的枝叶。今天的这篇文章，我将在这些“枝叶”中挑选几个我认为值得关注的，来仔细聊一聊。列存储索引（Columnstore Indexes）和Hekaton内存数据库是新版SQL Server中很重要的两个功能，它们都是跨时代的技术革新，能够大大提升SQL Server数据库的性能。

　　列存储索引

　　列存储索引是SQL Server 2012版本中自带的功能，它的前身是开发用来进行 PowerPivot内存存储的功能。列存储同传统的关系型数据库中行存储有着本质上的不同，数据按照列布局的方式存储，能够将上百万个列值全部聚合到一个blob结构当中。同时这个结构还能提供让人意想不到的数据压缩比。

　　快速批处理模式还能够加速SQL Server 2012数据库的查询过程。正如David Dewitt博士在两年前的SQL PASS大会上所做的演示，连续列值的紧密结构，通过将数据在缓存和CPU之间的来回移动次数减小到最小，从而能够充分利用现代CPU技术所提供的优势。

　　当然，列存储索引也并非无懈可击，它有一个非常大的局限性——只读。这意味着表索引也是只读的。所以任何一个拥有列存储索引的表，它是不允许任何插入、更新以及删除操作的。要对数据进行修改，就必须先删除列存储索引限制，然后再对数据进行增删改，最后重建列存储索引。由此可以看出，这对于OLTP系统的用户友好度是有欠缺的。因此可以说，列存储索引仅对处理数据仓库和OLAP负载有优势。在下一版本的SQL Server中，微软已经承诺进行改进，去掉更新数据的限制并允许进行列存储的聚集索引（clustered index）。

　　对于这个功能，我曾经也做过一些实验。我发现当查询的性质与列存储相吻合的时候，它的性能提升是显而易见的。一般来说，一个表中的列越多，列存储索引的施展空间就越大，它能够避免SQL Server去读取更多的索引部分。在另一种情况下，针对相对列数较少的实体-属性值表，所得到的结果就要分开来说。汇总查询要快得多，从300秒降到了3秒钟。但是返回一个小行集的所有列时，它起到的作用就不大。

　　Hekaton内存数据库

　　当列存储索引将数据仓库应用性能提升一个档次时，微软的另一个项目正在将目标瞄准OLTP系统，它就是Hekaton内存数据库。网站、邮件服务器、ERP系统以及订单录入系统等，它们每一秒钟执行着大量的交易（一笔交易通常是比较小的），而这些系统正是Hekaton的目标群体。Hekaton事实上算是SQL Server的一个扩展，可以把它看做是一个内存数据库，它将在下一版本的SQL Server中正式发布，而目前的发布日程还没有最终公布。

　　Hekaton先从存储在磁盘中的表入手，将它们完全放入到RAM当中。这意味着它将限制在较小的表之上，或者可以设计一个结构将活跃数据与历史数据进行分割。随着硬件设备的不断更新，RAM变得越来越大，从500 GB到上TB不等，对于存储应用系统的活跃数据，这么大的RAM是绝对够用了，这也是Hekaton应运而生的一个原因。

　　在Hekaton系统中，DBA能使用T-SQL进行编码，这让它的使用门槛降低了许多。但要注意的是，与传统T-SQL还是有所不同，Hekaton代码将编译成原始的机器语言而且不带解释器。T-SQL在数据操控方面很好用，但是辅助业务逻辑不是它的强项；本机编译能够对其进行良好的提速效果。

　　随着服务器的处理器核心越来越多，进行纵向扩展时的资源争用问题将会变得更加严重。Hekaton通过部署自身的锁定机制来避免这一问题，它对交易进行优化，来更加适应内存数据库，能够让多个交易同步地运行。然而，它的限制是如何将Hekaton表和其他表进行联合。

　　通过内存数据处理、编译代码以及新的并发控制机制，Hekaton最初的基准测试数据相当吸引人。在SQL PASS 2012大会上，我看到开发人员的现场演示，其中吞吐量提升了25倍，是25倍，而不是25%哦!这只是Hekaton的初亮相，最终微软会给出我们怎样的答案，我会拭目以待。