Sam Asked: 2018-02-19 11:12:37 +0800 CST2018-02-19 11:12:37 +0800 CST 2018-02-19 11:12:37 +0800 CST CPU 时间与 SQL Server 事件探查器中读取的差异 772 我的生产数据库服务器 SQL Server 2016 性能下降,我使用分析器保存了长时间运行的查询,如下图所示: CPU 时间 = 65141,读取 = 36474959,持续时间 = 114546 我已经保存了跟踪文件并稍后打开,所以我不确定持续时间是毫秒还是微秒。 但是,现在当我在工作时间之外对产品运行相同的查询时,查询运行速度很快并且“设置统计信息 IO”显示只读取了很少的数据页,我的假设是 CPU 时间并且查询的读取应该是恒定的查询的执行时间尽管有持续时间,有什么想法吗?我是否应该根据数字认为此查询效率低下? sql-server performance 1 个回答 Voted Best Answer Anti-weakpasswords 2018-02-19T19:21:49+08:002018-02-19T19:21:49+08:00 @DanGuzman 正确地向您指出了Sommarskog 的优秀文章,您应该阅读它。 然后,如果以下简单步骤不起作用,请尝试查看计划缓存并查看其中的内容。或者使用查询存储,因为您使用的是 SQL 2016,以查看有多少不同的执行计划。 您正在将 SET STATISTICS(任何内容)与 Profiler 进行比较。不要那样做。它不起作用。Profiler 和扩展事件捕获相对准确的数字。SET STATISTICS (anything) 没有 - 作为一个例子,它不捕获函数成本! 您正在尝试匹配在不同时间完成的计划,可能具有不同的统计数据。不要那么做。 继续并更新可疑查询中涉及的所有表的统计信息,最好使用 FULLSCAN,在您“自己运行”测试之前,先看看是否改变了行为。 查看查询本身。 是否涉及参数嗅探? 是否经过合理格式化后有数千行长,有几十个连接,通常是同一个表?如果是这样,请停止让 Entity Framework 尝试自行创建复杂的 SQL 语句。它做得很糟糕。
@DanGuzman 正确地向您指出了Sommarskog 的优秀文章,您应该阅读它。
您正在将 SET STATISTICS(任何内容)与 Profiler 进行比较。不要那样做。它不起作用。Profiler 和扩展事件捕获相对准确的数字。SET STATISTICS (anything) 没有 - 作为一个例子,它不捕获函数成本!
您正在尝试匹配在不同时间完成的计划,可能具有不同的统计数据。不要那么做。
继续并更新可疑查询中涉及的所有表的统计信息,最好使用 FULLSCAN,在您“自己运行”测试之前,先看看是否改变了行为。
查看查询本身。