6

阅读 SQL Server 2014 中的聚集列存储索引，我想知道是否拥有一个包含大量列的表仍然是一种反模式。目前，为了缓解单个表包含大量列的问题，我正在使用垂直分区，但有可用的聚集列存储索引，这不应该是必需的。这是正确的还是我错过了什么？

示例： 让我们以性能计数器的日志为例，原始数据可能具有以下结构：

╔══════════════════╦═══════╦═══════╦═════╦═════╦══ ═══╦══════════╗
║ 时间 ║ 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 将仅涉及请求的列，无论在桌子。

4

2 回答 2

1

它肯定没有横向存储那么“糟糕”，但是 1000 把限制推得太远了。我们的数据仓库通常有 100 到 200 列的表，并且它们的列存储索引足够快。假设你有完美的列存储索引，每个查询应该只查看特定的垂直索引，因此非常有效。但是，如果您的列存储索引对于查询来说不是最佳的，SQL Server 必须在索引之间进行一些跳转，而这些索引并不好。

这没有经验法则。您必须进行基准测试才能在您的特定环境中回答这个问题。

于 2013-11-04T19:31:01.933 回答
-1

工作负载中的查询类型和表中的数据类型是决定行存储还是列存储会给您带来更好好处的因素。如果查询正在查找一小组行，行存储可能会提供更好的性能。如果查询是数据仓库类型的查询，例如 - 扫描大量数据，列存储将提供更好的性能。此外，您可以在表上创建非聚集列存储索引。查询优化器将决定何时使用列存储索引以及何时使用其他索引。

我建议在此处阅读包含列存储索引常见问题列表的 TechNet 文章。

于 2014-05-21T23:23:09.793 回答