[Cross从数据库管理员站点发布，希望它可以在这里获得更好的牵引力。我会根据需要更新任一网站。]
我在SQL Server 2005（SP2）中有一个存储过程，其中包含如下所示的单个查询（为简洁起见，已简化）
SELECT * FROM OPENQUERY(MYODBC, 'SELECT * FROM MyTable WHERE Option = ''Y'' ')
OPTION (MAXDOP 1)
当运行此proc（并且仅运行一次）时，我可以看到该计划出现在具有高“total_worker_time”值的sys.dm_exec_query_stats中（例如，34762.196 ms）。这接近经过的时间。但是，在SQL Management Studio中，统计信息显示CPU时间要低得多，正如我所期望的那样（例如6828 ms）。查询需要一些时间才能返回，因为它正在与之交谈的服务器速度很慢，但它不会返回很多行。
我知道SQL Server 2005中的并行查询会出现奇怪的CPU时间的问题，这就是为什么我试图通过查询提示关闭任何并行性（尽管我真的不认为有无论如何）。
我不知道如何解释这两种查看CPU使用情况的方法可能不同，也不知道两者中的哪一种可能是准确的（我有其他理由认为CPU使用率可能更高，但测量很棘手）。谁能给我一个转向？
UPDATE ：我假设问题出在OPENQUERY上，所以我尝试查看长时间运行的查询，但不使用OPENQUERY。在这种情况下，统计数据（通过设置STATISTICS TIME ON获得）报告CPU时间为3315ms，而DMV则为0.511ms。每种情况下的总经过时间达成一致。
答案 0 :(得分：0)
total_worker_time中的{p> sys.dm_exec_query_stats是累积的 - 它是当前编译的查询版本的所有执行的总执行时间 - 请参阅execution_count表示此代表的执行次数。
有关个别执行的时间安排，请参阅last_worker_time，min_worker_time或max_worker_time。