在我们的客户中，sql server被configuration为1并行度。 服务器有8个CPU，所以限制这个度数为1会是什么原因？
SQL Server将已经将多个查询放置到多个CPU（如果获得许可）。 在较大的查询中，它可以通过启用并行性来跨多个线程（以及可能的CPU）打破单个查询。
您应该设置并行度来匹配大型查询的一般大小。 如果您经常使用72连接查询敲击数据库，请将其设置为与服务器拥有（或获得许可）的CPU数量一致。 如果你不断地用小的查询来访问服务器，或者你不想让更大的查询接pipe所有的CPU，那么设置一个更保守的数字（比如1）。
这些是非常通用的指导方针，来自MS的并行查询处理的更多信息以及并行 度设置。
我经常看到的场景是一个查询在与并行执行时导致自身死锁; 这通常是索引错误或者写入更新/删除不好的迹象，但是有些人走的是匆忙而肮脏的路线，为了避免死锁而closures并行。
以下是我将如何回答，纯粹是基于我的经验和有限的知识：
SQL Server似乎决定是否在查询计划中使用并行性，主要是基于这是否有助于该查询的单个执行返回更快。 大多数情况下，这个评估是相当准确的。 有时候，优化器可能会做出一个不太好的select。 但是在任何情况下，它都没有考虑到该服务器正在发生什么。 特别是，如果您运行的是每秒处理大量批处理请求的服务器，并且这些批处理中的一些重要部分正在并行化，则可能会遇到线程匮乏。 也就是说，调度程序都忙于处理并行请求或等待它们，没有任何事情可以得到处理。 这可能performance为SQL Server的无响应。 请注意，您可能不一定会看到100％的CPU利用率。 你不在的CPU，它是可用的调度程序。 通常情况下，您将需要大量的CX_PACKET和THREADPOOL等待，并且跨调度程序的平均可运行任务数超过1。
在一些商店，工作量非常复杂，为了完全避免这个问题，需要做一个完全消除并行的战略决策。 据我所知，在某些情况下，这可以工作得很好，尽pipe我曾经和微软的工程师说过这个问题，他们认为这是一个误导性的，本质上是坏的想法。 在这种情况下，您不能加速并行性查询，所以执行时间通常与CPU利用率成正比。 这可以是一个可以接受的权衡，特别是如果你的大部分批量请求很小。