在SQL Server中，`sys.dm_os_waiting_tasks`是一个非常重要的动态管理视图，它提供了关于当前正在等待资源的任务的信息。这个视图对于诊断性能问题，尤其是锁定和等待问题，非常有帮助。在“SqlServer应用之sys.dm_os_waiting_tasks 引发的疑问(下)”这篇文章中，作者探讨了对并行执行的理解以及`sys.dm_os_waiting_tasks`在并行查询中的表现。
作者提到的并行查询并不像最初理解的那样，即多个线程同时扫描不同的表然后进行关联。通过实验，作者发现并行查询可能不是同时处理两个表的数据，而是根据执行计划的顺序来执行。在给定的例子中，尽管使用了并行选项（`OPTION (querytraceon 8649)`），但SQL Server选择先扫描T2表，导致只有T2表出现了锁等待（`lck_m_s`）。这表明并行执行可能是在操作符级别上进行的，而不是在表扫描阶段。
并行查询实际上是由SQL Server的并行度控制的，它会根据资源可用性、查询复杂度和成本估算来决定何时以及如何并行执行。并行查询通常在涉及大量数据处理或复杂计算时启用，以提高查询性能。但在某些情况下，如在处理小数据集或简单的查询时，SQL Server可能会选择串行执行，以避免并行带来的额外开销。
作者还提到了`UNION ALL`操作的问题，他们疑惑为何每个`UNION ALL`部分不能同时执行。这可能是因为`UNION ALL`操作本身是顺序的，每个子查询必须完成之后才能合并结果。虽然SQL Server可能在单个操作符内部实现并行，但在这种特定的查询结构中，各个`UNION ALL`部分的并行执行可能并不被支持。
文章中给出的测试代码展示了如何持续监控`sys.dm_os_waiting_tasks`，以便观察整个查询的等待行为。通过将等待任务按变量`@a`分组，可以跟踪不同阶段的等待事件，这对于分析并行执行过程中的等待模式非常有用。
`sys.dm_os_waiting_tasks`是SQL Server性能优化的关键工具，通过深入理解其输出和并行查询的工作原理，DBA和开发人员可以更有效地诊断和解决性能问题。在实践中，应结合其他动态管理视图，如`sys.dm_exec_requests`和`sys.dm_exec_sessions`，以获得更全面的性能洞察。同时，对于并行查询的理解，需要考虑SQL Server的执行计划、并行度策略以及资源调度等因素。
