我的猜测：发送最后一个请求字节和从服务器接收最后一个响应字节之间的持续时间.客户统计数据如下：
客户处理时间：90393
总执行时间：92221
等待服务器回复的时间：1828
我最好猜测分析器上的“持续时间”意味着“sql Server(优化引擎解析查询,生成查询计划或使用现有查询计划从不同页面获取记录)所花费的时间来生成结果集排除数据通过电线传输到客户端所花费的时间“
编辑：我发现这两个时间大致相同(管理工作室vs分析器).它们与我在客户统计中看到的时间有何关联？
有人可以对这些更加轻松吗？
解决方法
首先,从联机丛书中,SSMS将通过SET STATISTICS TIME ON报告的静态：
“Displays the number of milliseconds
required to parse,compile,and
execute each statement.”
你是这样的.至于Profiler中的持续时间,它被描述为：
“The duration (in microseconds) of the
event.”
从我所在的位置来看,这两个应该在功能上是等价的(并且,我确定你注意到,如果您违反sql 2005或更高版本,Profiler将以微秒为单位报告).我这样说是因为这种情况下的“事件”(关于Profiler中的持续时间)是select的执行,包括交付给客户端;这两种情况都是一致的.
您似乎怀疑地理位置是远程执行查询时长时间的罪魁祸首.这很好.您可以通过在一个查询窗口中对视图执行select然后生成另一个查询窗口并查看查询的等待类型来测试：
select
a.session_id,a.start_time,a.status,a.command,db_name(a.database_id) as database_name,a.blocking_session_id,a.wait_type,a.wait_time,a.cpu_time,a.total_elapsed_time,b.text
from sys.dm_exec_requests a
cross apply sys.dm_exec_sql_text(a.sql_handle) b
where a.session_id != @@spid;
如果地理位置问题,我会怀疑你会看到像ASYNC_NETWORK_IO这样的东西作为等待类型 – 否则,看看会发生什么.如果您正在分析远程执行的查询,则持续时间将反映您在SSMS中看到的时间统计信息.但是,如果您正在使用Profiler并且发现从与sql Server位于同一数据中心的其中一个Web服务器执行此查询的持续时间仍然需要7分钟,则DBA是一个大胖子:).我会使用Profiler来记录超过1分钟的查询,尝试过滤您的视图并获取平均值以查看您是否达到了性能目标.
因为没有张贴其他答案,我担心我会离开这里 – 但现在已经很晚了,我是新手,所以我想我会试一试！
