您好 SQL Server 社区，
我正在尝试加深对 SQL Server 工作线程的理解，特别是关于繁忙的 OLTP 系统中的最大工作线程设置。我目前正在与sys.dm_os_threadsDMV 合作，正在探索如何最好地优化我们服务器上的线程管理。
我目前的理解是，如果默认的最大工作线程设置不变，SQL Server会根据系统的工作负载自动管理工作线程。SQL Server 可能会分配更多工作线程来处理增加的工作负载，并可能在任务完成后回收或销毁这些线程，尽管这可能不会立即发生。
然而，我并不完全确定我的理解是否正确，特别是当涉及到 SQL Server 可能已达到创建新线程的限制时。如果发生这种情况并且仍然有新的传入请求，是否会导致“调度程序死锁”情况？我们最近在我们的环境中遇到了这样的问题，我正在尝试了解这是否可能是原因。
鉴于此背景，我有几个问题：
- 在繁忙的 OLTP 系统上，我们是否应该考虑更改由 Microsoft 公式计算出的最大工作线程设置的默认值？
- 如果我们应该改变它，这个数字应该大于默认值吗？
- 我们如何才能最好地确定特定环境的最佳最大工作线程数，以防止“死锁调度程序”问题？
我们将非常感谢您对此事的见解或建议。谢谢。
这是对的。
可以，完全取决于情况。假设系统正在运行并且刚刚达到资源限制，那么新连接将会失败，因为需要一个线程来为这些连接提供服务。这通常是您会开始看到的，以及服务器“缓慢”或“缓慢”，但这不是必需的。
当当前工作没有任何进展时，就会发生调度程序死锁，这几乎完全是由于阻塞造成的。
我不会，主要是因为您目前不知道为什么会遇到问题。假设它是阻塞的（同样，几乎总是如此）。你启动工作线程。现在，您不再是在 5 分钟时出现死锁调度程序转储，而是在 7 分钟时出现死锁调度程序转储。没有人真正从根源上引起了该问题，因此“解决方案”当然不起作用。这有什么注意事项吗？当然。这些是超级边缘情况吗？是的。
还有许多其他事情需要考虑，例如，人为增加线程数可能会使所有其他进程（不仅仅是 SQL）和所有其他查询执行速度变慢。每个线程都需要一块 CPU 蛋糕。如果 4 个核心上有 800 个线程，那么它们就足够了。如果 4 个核心上有 2400 个线程，那么您获得的资源会更少（假设线程需要工作，如果它们没有事情可做，那么仅仅旋转 2400 个线程并不会真正完成任何事情）。
不需要，一般来说，默认数字是一个相当不错的数字。线程数量本身（假设它没有设置得非常低以帮助强制这种情况）不是问题。首先是死锁调度程序问题的根本原因。改变 MWT 值几乎总是没有帮助，反而会成为障碍。