在 SQL Server 上使用并行性有哪些危险？

Question

在我们的一个客户那里，SQL 服务器的并行度配置为 1。该服务器有 8 个 CPU，那么将此度限制为 1 的理由是什么？

Answer 1

SQL Server 已将多个查询放入多个 CPU（如果获得许可）。对于较大的查询，它可以通过启用并行性将单个查询拆分到多个线程（可能还有 CPU）中。

您应该将并行度设置为与大型查询的一般大小相匹配。如果您不断使用 72 个连接查询访问数据库，请将其设置为与服务器拥有的（或许可的）CPU 数量相同。如果您不断使用小型查询访问服务器，或者您不希望较大的查询占用所有 CPU，则将其设置为更保守的数字（例如 1）。

这些都是非常通用的指导方针，更多信息请见 MS并行查询处理，以及并行度环境。

Answer 2

我经常看到的情况是，查询在并行执行时导致其自身死锁；这通常是索引不良或更新/删除写得不好的迹象，但有些人选择快速而肮脏的路线并关闭并行性以避免死锁。

Answer 3

以下是我根据我的经验和有限的知识做出的回答：

SQL Server 似乎主要根据并行性是否有助于该查询的单次执行更快地返回结果来决定是否在查询计划中使用并行性。大多数情况下，这种评估相当准确；偶尔，优化器可能会做出不太好的选择。但无论哪种情况，它都不会考虑该服务器上还发生了什么。特别是，如果您运行的服务器每秒处理大量批处理请求，并且这些批处理中的很大一部分正在并行化，则可能会遇到线程饥饿。也就是说，调度程序都在忙于处理并行请求或等待它们，并且什么都无法处理。这可以表现为 SQL Server 的无响应。请注意，您可能不一定会看到 100% 的 CPU 利用率。您没有 CPU，而是可用的调度程序。通常，您将看到很多 CX_PACKET 和可能的 THREADPOOL 等待，并且调度程序中的平均可运行任务数超过 1。

在一些商店中，工作负载非常复杂，因此需要做出战略决策，完全消除并行性，以彻底避免出现此问题。据我所知，在某些情况下，这种方法效果很好，尽管我曾与微软工程师交谈过，他们认为这是一个误导性的、本质上很糟糕的想法。在这种情况下，您无法通过并行性来加速查询，因此执行时间通常与 CPU 利用率成正比。这可能是一个可以接受的权衡，特别是如果您的大多数批处理请求都很小。