更新时间：2021-07-26 15:39
我们知道，在SQL Server里，Page是数据存储的基本单位，而数据行是实际数据的存储单位，它们从Page Header之后就开始依次存储在Page上。这种按行在Page上存储记录的方式就是行存储。当数据是按单列而不是多行进行连续存储时，就是所谓的列存储。
磁盘的每个Page仅仅存储来自单列的值，而不是整行的值。因此，压缩算法会更加高效，因为它们能够作用于同类型的数据。例如，假定我们有一张有3列数据的表，这3列从左往右依次是int、varchar和bool类型，并且该表有100条（行）记录。对于都是int类型的第一列数据，应用压缩算法是很容易的，同时压缩率也会很高。这也将表明，我们不必访问该表的所有列，仅需访问感兴趣的相关列的子集，这从另一方面来讲，可以减少磁盘的I/O、提升缓存利用率，因此，磁盘存储会被更加高效的利用，就像索引维护一样。
列存储适合用在什么场合?
OLAP，数据仓库，数据挖掘等查询密集型应用。当然，列存储数据库并不是说完全不能进行更新操作，其实它们的更新操作性能并不是很差，一般也够用，但是一方面不如自己的查询性能，另外一方面也不如Oracle这种专门搞OLTP的数据库，所以一般就不提这个。
列存储不适合用在什么场合?
相对来说，不适合用在OLTP，或者更新操作，尤其是插入、删除操作频繁的场合。
分列数据格式：每次对一个列的数据进行分组和存储。 SQL Server 查询处理可以利用新的数据布局，并显著改进查询执行时间。加快查询结果：列存储索引由于以下原因而可更快地生成结果：
（1）只须读取需要的列。因此，从磁盘读到内存中、然后从内存移到处理器缓存中的数据量减少了。
（2）列经过了高度压缩。这将减少必须读取和移动的字节数。
（3）大多数查询并不会涉及表中的所有列。 因此，许多列从不会进入内存。 这一点与出色的压缩方法相结合，可改善缓冲池使用率，从而减少总 I/O。
（4）高级查询执行技术以简化的方法处理列块（称为“批处理”），从而减少 CPU 使用率。
列存储索引的局限性
（1）包含的列数不能超过 1024。
（2）无法聚集。 只有非聚集列存储索引才可用。
（3）不能是唯一索引。
（4）不能基于视图或索引视图创建。
（5）不能包含稀疏列。
（6）不能作为主键或外键。
（7）不能使用 ALTER INDEX 语句更改。 而应在删除后重新创建列存储索引。
（8）不能使用 INCLUDE 关键字创建。
（9）不能包括用来对索引排序的 ASC 或 DESC 关键字。 根据压缩算法对列存储索引排序。 不允许在索引中进行排序。 可能按照搜索算法对从列存储索引中选择的值进行排序，但是必须使用 ORDER BY 子句来确保对结果集进行排序。
（10）不以传统索引的方式使用或保留统计信息。
（11）无法更新具有列存储索引的表。
内存受限的影响：列存储处理针对内存中处理进行了优化。 SQL Server 实现了若干机制，使得数据或大多数数据结构可以在可用内存不足时溢出到磁盘。 如果存在严重的内存限制，则处理过程将使用行存储。 在某些实例中，可能会选择列存储索引作为访问方法，但内存不足以生成所需数据结构。 通过先以列存储操作开始，然后默认为一个较慢的代码路径，在查询遇到严重内存限制时，可能会导致性能出现一定程度的降低。 任何查询的有效内存要求取决于特定的查询。生成列存储索引要求的内存量大约为：8 MB×索引中的列数×DOP（并行度）。通常，内存要求随着作为字符串的列的比例提高而增加。 因此，降低 DOP 可以减少生成列存储索引所需的内存。
一些表达式的计算将比其他表达式更快：当使用列存储索引时，应使用批处理模计算某些常见表达式，而不以一次一行的模式进行计算。 除了使用列存储索引所带来的优势之外，批处理模式还将提供其他查询加速效果。 并不为批处理模式处理启用每个查询执行运算符。
列存储索引不支持 SEEK：如果查询应返回行的一小部分，则优化器不大可能选择列存储索引（例如：needle-in-the-haystack 类型查询）。如果使用表提示 FORCESEEK，则优化器将不考虑列存储索引。
列存储索引不能与以下功能结合使用：页和行压缩以及 vardecimal 存储格式（列存储索引已采用不同格式压缩），复制，更改跟踪，变更数据捕获，文件流。
SQL Server 2012所提供的列式索引及其相关查询功能在技术上取得了突破性的进展，可以为数据仓库查询提供空前的性能优势。企业的最终用户可以使用熟悉的报表工具，在更短的时间内从数据中获取商业价值，他们将成为最主要的受益者。