我们正在运行每日批处理，有时会看到20个运行时差异因素。 分析记录快速和慢速性能时间帧的跟踪我隔离了一个select语句，该语句从聚簇索引中返回单行，该聚合索引在＆＃34; fast＆＃34;中记录持续时间为1101 micos（3个逻辑读取）。大体时间。 几分钟后，使用相同计划的相同选择持续28±275微秒（3个逻辑读数）。 两个时间帧（快/慢）都处于预先工作时间，服务器上几乎没有其他活动。 它是运行SQLServer 2012的AlwaysOn集群，CPU使用率始终低于30％，并且由于大量RAM低IO活动。 对我们来说，痕迹并没有揭示持续时间长的原因。我们可以追踪哪些建议以获得更多洞察力？ 谢谢 Juerg 加成： 添加了一些动作的跟踪，发现了另一个奇怪的事情。该应用程序使用动态SQL命令从具有不同PK的同一表中请求相同的数据（从t1中选择*，其中OID =＆＃39; ...＆＃39;）。它连续4次执行，并且exec计划对于所有4个选择是相同的（1个索引查找和1个键查找）。每个选择触发8个位点读数。 4个中的3个选择跟踪中的log 0 ms CPU时间和15 ms中的1个日志？ 我是对的，即使是物理读取（无法在跟踪中看到但是我们有大量的RAM并且我怀疑物理读取是否发生）不应该增加CPU数量？什么可能导致该计数器与其他读数相比如此之高？