我刚刚了解了列存储索引的奇妙之处，以及如何“使用列存储索引实现比传统的面向行的存储高达 10 倍的查询性能提升，以及高达 7 倍的未压缩数据大小的数据压缩。”
有了如此可观的性能提升，真的有理由不使用它们吗？
【问题讨论】：
标签： sql sql-server database tsql optimization
主要缺点是如果查询包含选择性谓词，您将很难仅读取索引的一部分。有很多方法可以做到这一点（分区、段消除），但这些方法既不是特别容易可靠地实现，也不能扩展到复杂的需求。
对于仅扫描工作负载，列存储索引非常理想。
【讨论】：
Email = ... 或SomeCol > 3 读取索引的范围。他们不碰其余的。使用列存储索引很难做到这一点。
列存储索引对于数据仓库 (DW) 尤其有益。这意味着您只会在特定时间执行更新或删除。
这是由于它们具有增量加载和更多功能的特殊设计。该视频将详细展示 Columnstore Index 的确切区别和一个很好的基本概述。
如果您的应用程序的I/O（输入和输出）很高；列存储索引并不理想，因为传统的行索引 会在特定目标上查找和操作（使用通过索引找到的行）。这方面的一个例子是 ATM 应用程序，它经常更改给定人员帐户的 行 的值。
列存储索引索引贯穿整个COLUMNS，这在这种情况下并不理想，因为行值将分布在整个分段（columnsindexes）中。
我强烈推荐这个视频！
我还想详细说明非集群与集群列存储：
非集群列存储（2012 年更新）再次保存 WHOLE 数据，这意味着（2X 数据）数据的两倍。
作为聚集列存储索引（2014 年更新）仅占用 5MB 即可存储约 16GB 的数据。这是由于 RTE（运行时编码）在每列中保存了重复数据的数量。使索引占用更少的额外存储空间。
【讨论】：
你好阿很detailed explanation of columns store index可以找到here。
列存储索引
列存储索引是一种使用称为列存储的列数据格式存储、检索和管理数据的技术。
此功能已在 SQL Server 2012 中引入，旨在显着加快常见数据仓库查询的处理时间。列存储索引的主要目标适用于典型的数据仓库数据集，并在从庞大的数据集中提取数据时提高查询性能。
它们是基于列的索引，能够为常见的数据仓库查询（例如过滤、聚合、分组和星型连接查询）提供更快的性能，从而转变用户的数据仓库体验。它们按列而不是按行存储数据，就像目前的索引一样。
【讨论】：