我们正在尝试监控 SQL 工作线程，过去我们使用以下查询：
SELECT SUM(current_workers_count) as [Current worker thread] FROM sys.dm_os_schedulers
我们现在正在考虑只为每个 SQL Server 实例使用 PerfMon 计数器“Process>Thread Count”。在我们的分析过程中，我们注意到 PerfMon 线程计数与 dm_os_scheduler 或 dm_os_workers 中的工作线程之间存在细微差别。我们还将它与 dm_os_threads 中的内容进行了比较，仍然发现了差异。有谁知道 Microsoft 提供的 DMV 中跟踪的内容与 PerfMon 捕获的内容之间的区别？DMV 始终低于性能监视器中的值，因此它们必须“排除”某些东西。我们需要了解那是什么。
例如，dm_os_threads dmv 将显示 137，但性能计数器将显示 141，dm_os_scheduler 和 dm_os_workerss dmv 将分别显示 122 和 123。
我们使用的是 SQL Server 2017，CU22；视窗服务器 2016
我最初关于线程使用的讨论可以在这个答案中阅读。
线程 DMV 只会公开 SQL Server 知道的线程，因此它只会有它引导的线程。本质上，您只会看到 SQL Server 直接或间接启动并将某些数据结构挂钩到 TLS 的线程。
一个简单的例子是，假设我有一个 3rd 方防病毒应用程序，我们称之为“Sarbon Yack”或简称 SY。SY 可能会自行将自己的模块加载到 SQL Server 内存空间中——这是不受支持的。当这些模块被加载时，它们可能会启动许多不同的线程——但是通过引擎启动它们的不是 SQL Server，实际上是一个外部模块启动了它们。从技术上讲，它们存在于流程的范围内并被报告，但 SQL Server 不知道它们的存在，并且它们没有附加任何 SQL Server 数据结构。这些线程不会出现在 DMV 中。
我不知道 perfmon 的代码，但 perfmon 不会创建值，它只是在要求返回值时从不同的数据源读取（例如通过添加计数器）。我的直觉告诉我，当在进程空间中创建线程时，内部值会增加，而当线程被任何跟踪它的代码破坏时，内部值会被删除。
该值本身不知道 SQL Server 是什么或它如何使用线程，它只是查看一个抽象的“进程”（这是您将在每个进程下找到线程值的内容）并读取有关数字的信息线程，然后返回该值。它不区分什么是 SQL 增强线程和什么不是。
我对如何做到这一点的最佳猜测可能是调用NtQuerySystemInformation for SystemInformation，它将返回一个System_Process_Information结构列表，该结构将保存进程中的线程数。我最好的猜测是（线程数）是通过遍历 _EPROCESS 数据结构中的线程列表来合并存在的——但在内核或用户模式结构中的某处也可能有一个针对这个特定事物的计数器，而我只是不这样做'看不到它或知道它的存在。
_EPROCESS 中的线程列表：