小编Gio*_*Gio的帖子

我知道什么是参数嗅探，但这似乎不同，我有一个简单的查询：

select * from A400RDATA

该表只有 acluster index和大约25000行。查询通常需要 1 秒，但现在需要 20 秒。

我在缓存中找到了它的执行计划，并使用sp_BlitzCache（感谢 Brent Ozar）分析每个细节 -> 是的，最后一次执行需要 20 秒。

因此，我稍作更改，再次运行此查询，前导空格：“ select * from A400RDATA”（注意sof之前的前导空格select）。前导空格是查询文本中的更改，因此会SQL Optimizer生成新的查询计划。

这两个查询计划是相同的，它们是平凡的计划，它们只是使用cluster index，但总读取和持续时间不同。遵循两种不同的 BlitzCache 结果：

Solarwind 显示下降Page Life Expectancy，并且 SQL Server 实例仅使用一个核心 ( MAXDOP = 1)。
我认为MAXDOP并且PLE可能是问题的原因，你怎么看？我怎么能确定呢？
我如何知道数据是从磁盘还是 RAM 中获取的？

我检查了20秒执行计划的逻辑和物理读取：

• 执行时间：3
• 物理读取：0
• 处理的行数：76000
• 逻辑写入：0
• 逻辑读取：3841

没有物理读取......所以PLE不是原因（也许）。我再次阅读了计划的详细信息：3 次执行和 20 秒的总持续时间，因此每次执行需要 6 秒，但 CPU 时间相对较少： …