测量查询性能：“执行计划查询成本”与“所用时间”

我正在尝试确定两个不同查询的相对性能，并且有两种可用的方法来衡量它：
1. 运行两个查询并对每个查询计时
2. 运行两者并从实际执行计划中获取“查询成本”

这是我运行的用于计时查询的代码......

DBCC FREEPROCCACHE
GO
DBCC DROPCLEANBUFFERS
GO
DECLARE @start DATETIME SET @start = getDate()
EXEC test_1a
SELECT getDate() - @start AS Execution_Time
GO

DBCC FREEPROCCACHE
GO
DBCC DROPCLEANBUFFERS
GO
DECLARE @start DATETIME SET @start = getDate()
EXEC test_1b
SELECT getDate() - @start AS Execution_Time
GO

我得到的是以下内容：

Stored_Proc     Execution_Time     Query Cost (Relative To Batch)

test_1a         1.673 seconds      17%
test_1b         1.033 seconds      83%

执行时间的结果与查询成本的结果直接矛盾，但我很难确定“查询成本”的实际含义。我最好的猜测是它是读取/写入/CPU_Time/等的集合，所以我想我有几个问题：

1. 是否有明确的来源来解释这项措施的含义？

2. 人们还使用哪些其他“查询性能”指标，它们的相对优点是什么？

值得注意的是，这是一个中型 SQL Server，在 MS Server 2003 企业版上运行 MS SQL Server 2005，具有多个处理器和 100 多个并发用户。

EDIT:

经过一番麻烦之后，我设法获得了 SQL Server 上的 Profiler 访问权限，并且可以提供额外的信息（它支持与系统资源相关的查询成本，而不是执行时间本身......）

Stored_Proc    CPU      Reads    Writes   Duration   

test_1a        1313     3975     93       1386
test_1b        2297     49839    93       1207

令人印象深刻的是，使用更多的 CPU 和更多的读取花费的时间更少:)

分析器跟踪将其置于正确的位置。

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

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

查询 A 可能不是：CPU

这解释了相对于批处理的成本：较简单的非并行查询计划的成本为 17%。

优化器发现查询 B 的成本更高，并且会从并行性中受益，尽管这样做需要额外的努力。

但请记住，查询 B 使用 2 个 CPU 的 100%（因此 4 个 CPU 为 50%）持续一秒左右。查询 A 使用 100% 的单个 CPU 时间为 1.5 秒。

查询 A 的峰值较低，但代价是持续时间增加。 对于一个用户，谁在乎呢？有了100个，也许就会有所不同......