阅读SQL Server 2014中的聚簇列存储索引，我想知道是否有一个包含大量列的表仍然是一个反模式。 目前为了缓解具有大量列的单个表的问题，我使用vertical partitioning但是具有聚类列存储索引可用，这不应该是必需的。这是正确的还是我错过了什么？
示例： 让我们以性能计数器的日志为例，原始数据可能具有以下结构：
╔══════════════════╦═══════╦═══════╦═════╦═════╦═════╦══════════╗ ║ Time ║ Perf1 ║ Perf2 ║ ... ║ ... ║ ... ║ Perf1000 ║ ╠══════════════════╬═══════╬═══════╬═════╬═════╬═════╬══════════╣ ║ 2013-11-05 00:01 ║ 1 ║ 5 ║ ║ ║ ║ 9 ║ ║ 2013-11-05 00:01 ║ 2 ║ 9 ║ ║ ║ ║ 9 ║ ║ 2013-11-05 00:01 ║ 3 ║ 2 ║ ║ ║ ║ 9 ║ ║ 2013-11-05 00:01 ║ 4 ║ 3 ║ ║ ║ ║ 9 ║ ╚══════════════════╩═══════╩═══════╩═════╩═════╩═════╩══════════╝
拥有1000列这样的表是邪恶的，因为一行很可能跨越多个页面，因为通常不太可能会对所有度量感兴趣，但查询总是会产生IO成本等..等.. 要解决此问题，垂直分区通常会有所帮助，例如，可以按类别（CPU，RAM等）对不同表中的性能计数器进行分区。
相反，将这样的表作为聚簇列存储索引不应该是一个问题，因为数据将按列存储，并且每个查询所涉及的IO将仅仅 所请求的列，无论表格中的列总数如何，都不再是。
答案 0 :(得分：1)
它肯定不如水平商店“糟糕”，但1000推动限制有点太过分了。我们的数据仓库通常有100到200列的表，并且它们与列存储索引足够zippy。假设您有完美的列存储索引，每个查询应该只查看特定的垂直索引，因此非常有效。但是，如果您的列存储索引不是查询的最佳值，那么SQL Server必须在索引之间进行一些跳转，这些索引并不好。
关于这一点没有经验法则。您必须在特定环境中对基准来回答这个问题。
答案 1 :(得分：-1)
工作负载中的查询类型和表中的数据类型是决定rowstore或columnstore是否会为您带来更多好处的因素。如果查询正在查找一小组行，则rowstore可以提供更好的性能。如果查询是数据仓库类型的查询，例如 - 扫描大量数据，columnstore将提供更好的性能。此外，您可以在表上创建非聚集列存储索引。查询优化器将决定何时使用列存储索引以及何时使用其他索引。
我建议阅读包含列存储索引here的常见问题列表的TechNet文章。