随着列存储索引的出现，有关“并行成本阈值”设置的指南是否发生了变化？

Question

首先，我不是在问什么。我不是问我的设置应该是什么。

许多人建议将值提高到超过默认值，我当然理解为什么基于 B 树的查询会出现这种情况。但我一直在阅读有关内存中聚集列存储索引的（几乎）线性可扩展性，我想知道将成本阈值设置得太高是否会导致 SQL Server 使基于列存储的 CPU 内核查询饿死。

所以问题是：当涉及到“并行成本阈值”时，​​SQL Server 是否会以不同的方式对待列存储索引，这是否会导致我改变关于初始设置应该是什么的决定？

Answer 1

除了成本阈值设置之外，SQL Server 似乎会根据您的 SQL Server 版本（2012 与 2014）甚至表中的数据类型对列存储索引的并行性进行不同的处理。

我将从Joe Chang 的帖子基准十进制与浮点数据类型开始，并阅读该帖子的评论。如果您想为您的系统获得完全正确的并行设置的 MAXDOP 和成本阈值，您需要执行 Joe 在他的帖子中所做的详细测试级别，这需要大量工作。因此，我会首先关注您系统的主要瓶颈——使用等待统计信息来确保并行性或 CPU 压力对您来说是问题，然后从调整 CPU 密集程度最高的查询开始，而不是更改系统设置。

Answer 2

TL;DR：您读到的建议初始设置 50仍然是一个不错的起点。每个 NUMA 节点 1 个物理核心的 MAXDOP 对于像我们这样的服务器来说是一个很好的设置，它同时提供 OLTP 和 OLAP 工作负载。

推论：SQL Server 确实非常擅长它的功能。

我对这个设置的主要担忧是我是否会禁止在基于聚集列存储的索引上并行执行应该是非常短的查询。设置为 50 会导致低于 1 秒的查询花费更多时间吗？由于列存储索引与 CPU 的扩展性如此之好，是否会忽略“并行性成本阈值”设置？

• 问：SQL Server 甚至会尊重列存储索引的“并行成本阈值”吗？

• 答：是的。 当配置为 30,000 的荒谬设置时，列存储索引的并行性对于我的工作负载被有效禁用。尝试其他一些仍然令人讨厌的值 (1,500) 会抑制名义上需要大约 1 秒运行的工作负载的并行性，但名义上运行大约 10 秒或更长时间的查询表现出并行执行计划。

• 问：默认设置 50（如某些清单中指定的那样）是否是一个不会抑制基于列存储的查询的并行性的安全值？

• A:是的，而且远射。即使将该值提升到 500 仍然允许基于简单、短（亚秒）列存储的查询的并行性。

关于我的服务器、工作量和结果：

• 2 个 Xeon E2650v2，（2 个 NUMA 节点，12 个物理内核，24 个 HT 线程），384 GB RAM
• MAXDOP 配置为 6（每个 NUMA 节点 6 个物理内核）
• SQL Server 2014 企业版 CU4
• 在 6 个分区中测试 111,000,000 行聚集列存储索引（按年份）

测试了两个工作负载：

• SELECT COUNT(DISTINCT <low cardinality column>) FROM table;

• SELECT COUNT(DISTINCT <high cardinality column>) FROM table;

高基数列的查询在阈值超过 1500 时需要 84 秒（已过去），在该数字以下的阈值时需要大约 14 秒（已过去）。低基数列的查询在阈值 500 及以下花费了大约 250 毫秒（经过），在阈值高于 1500 时花费了 18（经过）秒。（我没有试图衡量它切换计划的确切点。）足够有趣, 当并行性被抑制时，低基数查询的总 CPU 时间急剧增加；也许服务器停止为此查询使用批处理模式。

呵呵，最终运行测试会导致更多问题，但这都是博客素材，超出了这个问题的范围。