Mar*_*erg 2 sql-server deadlock parallelism max-connections
这是一个非常笼统的问题，所以我不提供太多具体信息。我对并行性及其可能的缺点更感兴趣。一般来说，我完全支持并行性，因为它是有用和积极的。
我似乎遇到越来越多的系统，这些系统拥有一个或多个存储过程，但这些存储过程存在过多的并行性问题。有没有什么好方法可以确定这是否真的是问题所在，或者是否还有其他潜在问题？
通常 sql 有点复杂，可能有 5 个或更多连接，还有一些 udf 甚至更复杂。到目前为止，我通过检查所有常见的性能问题以及更极端的情况（如“无法创建线程...”）以及同一存储过程的多个同时副本导致的死锁，发现了这些问题。
我真的很好奇你们是如何找到这些问题的，以及如何解决这些问题。重新编码？玩MAXDOP（最大并行度）？等等...
我在这里写了关于并行性的六个潜在问题：
那是三年前的事了，我敢肯定，自从我写那篇文章以来，其他同样危险的错误已经出现了。我还没有经过并验证任何已报告为已修复的问题，但解决方法几乎总是使用MAXDOP 1.
还有另一个问题在 SQL Server 2012 中仍然存在，并且在 CU1 中尚未修复：
在这种情况下的解决方法是再次使用MAXDOP 1.
还有其他一些问题可以归咎于并行性，但实际上并不是并行性的错。例如，如果您的统计数据很远，您可以观察采用并行性但单个线程正在完成所有工作的行为。在这种情况下，人们发出警报是因为他们看到了CXPACKET等待，并且他们认为并行性导致了问题，而实际上它是受害者。在这些情况下，下意识的反应通常是采用MAXDOP而不是进一步调查和解决统计问题或其他根本原因。
不清楚您所说的“并行过多”是什么意思，或者您的死锁和其他问题实际上是否与并行有任何关系。总的来说，我同意并行性是一件积极的事情，但重要的是要意识到上述潜在问题，并且能够区分症状和原因。