探查器跟踪将其放入透视图.

The profiler trace puts it into perspective.

• 查询A:1.3秒CPU，1.4秒持续时间
• 查询B:CPU为2.3秒，持续时间为1.2秒

查询B使用并行性:CPU>持续时间 例如查询使用2个CPU，平均每个1.15秒

Query B is using parallelism: CPU > duration eg the query uses 2 CPUs, average 1.15 secs each

查询A可能不是:CPU<持续时间

Query A is probably not: CPU < duration

这说明了相对于批处理的成本:对于简单，非并行的查询计划，成本为批处理成本的17％.

This explains cost relative to batch: 17% of the for the simpler, non-parallel query plan.

优化器表明查询B更昂贵，并且可以从并行性中受益，即使这样做会花费更多的精力.

The optimiser works out that query B is more expensive and will benefit from parallelism, even though it takes extra effort to do so.

不过请记住，查询B使用2个CPUS的100％(4个CPU为50％)一秒钟左右.查询A使用单个CPU的100％的时间为1.5秒.

Remember though, that query B uses 100% of 2 CPUS (so 50% for 4 CPUs) for one second or so. Query A uses 100% of a single CPU for 1.5 seconds.

查询A的峰值较低，以增加持续时间为代价. 与一个用户一起，谁在乎?加上100，也许会有所不同...

The peak for query A is lower, at the expense of increased duration. With one user, who cares? With 100, perhaps it makes a difference...