SqlServer应用之sys.dm_os_waiting_tasks 引发的疑问(下

经过深入研究和分析，我对 SQL Server 中的 sys.dm_os_waiting_tasks 有了更深入的了解。针对您提到的疑问，我将以生动的语言和丰富的文体进行阐述。

关于并行的理解。起初，我以为并行查询会同时为每张表开启多个线程，但实际上，SQL Server 的并行处理并非简单地对每张表进行多线程操作。通过执行计划，SQL Server 会将查询分解成多个操作，然后尝试并行执行这些操作。但这并不意味着会对每张表开启单独的线程。例如，您提到的查询：

```sql

select from t1 inner join t2 on t1.a = t2.a

OPTION (querytraceon 8649)

```

SQL Server 会根据执行计划决定如何并行处理这个查询。它可能不会为每张表启动单独的线程，而是根据操作进行优化。我们在使用 sys.dm_os_waiting_tasks 观察等待情况时，会看到与查询执行计划相关的等待，而不是简单的表级别等待。

关于您提到的锁的问题，当我们在事务中更新表时，锁的行为确实会影响查询的等待情况。在您的例子中，更新 t2 表时，sys.dm_os_waiting_tasks 显示与 t2 相关的锁。这说明并行处理并没有导致同时对两张表进行扫描并产生锁。相反，它是根据执行计划决定先扫描哪张表，并在该表上产生锁。

至于 union all 的问题，每个 union 部分不能执行的原因可能与操作符级别的并行处理有关。在 SQL Server 中，union 操作本身是顺序执行的。即使存在并行处理，union 操作符可能不会被并行化，因为它需要等待前面的查询完成后再进行合并。这也是为什么在某些情况下，union all 的每个部分并不能并行执行。