请参阅此 SQL Profiler 视图中指示的 SQL 语句。所有这些事件都来自一台客户端计算机，该计算机正忙于长时间运行的进程，处理数千行。每次处理一行大约需要 6.5 秒，这是 SQL Profiler 显示的注销之间的时间，尽管实际的更新语句只需要 1 毫秒。每次登录/注销都使用相同的 SPID。请注意，在任何给定的登录和注销事件之间，SQL 语句指示读取计数为 17，写入计数为 0。
然而，注销事件表明总读取次数超过 200 万次，写入次数超过 10k。我需要分析哪些事件才能找出导致这些读/写的语句，因为我怀疑这些事件导致了 6.5 秒的延迟，但我看不到它们发生？
Audit:Logout 事件给出的读/写数字是该连接持续时间的累积总数。这些值本身并不会告诉您任何细节 - 如果您在连接的生命周期内运行 10 个命令，您将看到该会话中所有 10 个命令的总数。
要了解按语句进行的细分，您需要查看在开始 Audit:Login 事件和结束 Audit:Logout 事件之间为同一 SPID 记录的 SQL:BatchCompleted（或 SQL:StmtCompleted）事件。
Update:查看图像，看起来有点奇怪（至少对我来说）是，在每次 Audit:Logout 之后，Reads 值不会重置，因此每次它都会增加语句的读取次数被处决（17）。我不确定 100%，因此该数字将在什么时候重置 - 但基本点是该数字是累积的，并且可能是随着时间/大量陈述而建立的，因此并不一定意味着您有一个沉重的负担查询命中服务器！
我怀疑 Audit:Logout 的读/写数据的累积行为如上所述。但持续时间却扭转了这一趋势。看起来持续时间不是累积的。
一些描述来自MSDN http://msdn.microsoft.com/en-us/library/ms175827.aspx:
持续时间：自事件发生以来的时间量
用户登录（大约）。
内容如下：
发出的逻辑读 I/O 数量
连接期间的用户。
写入：逻辑写入 I/O 数
用户在使用期间发出的
联系。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
