执行计划中的实际行数与返回的实际行数不同答案

【问题标题】：Actual Number of Rows in Execution Plan is different than actual rows returned执行计划中的实际行数与返回的实际行数不同
【发布时间】：2019-11-30 14:42:41
【问题描述】：

我研究了一些关于“实际行数”的问题，但没有一个与我的问题相符，因此发布了它。另外，我研究了https://www.sqlpassion.at/archive/2018/05/28/actual-number-of-rows-are-not-always-accurate/，了解实际行不同的原因，但此博客谈到与我的表无关的非聚集列存储索引。

使用https://data.stackexchange.com/stackoverflow/，查询包含“实际执行计划”的Users表-

SELECT TOP 10 Location FROM Users WHERE Location = 'Hyderabad'
SELECT TOP 10 Location FROM Users WHERE Location LIKE 'Hyderabad'

结果附后。 StackOver_Top10HydUsers_ActualExecPlanIssue.Jpg 问题是（基于我对 WHERE 运算符如何工作的理解）-

两个查询都产生了相同类型的执行计划。但两者在计划中都显示了不同的“实际行数”。如何以及为什么？
两个计划的“实际行数”都是错误的，因为两个查询返回 10 条记录。那么，“实际行数”是用词不当吗？一世研究了为什么 Estimated Rows 基于统计原因而有所不同但“实际行”也是！？

-- 在“想法”中……

更新#1：实际上，我打算了解 ActualRows 与返回的内容有何不同，即使在 PhysicalOp Clustered Id Scan 发生后实际计算了满足 WHERE 的记录。

【问题讨论】：

下载数据库文件，安装sql server，恢复数据库，在本地机器上运行SSMS查询，看看执行计划是否一样。
我看到两个查询的实际行 10。看看您是否可以重复您的观察并上传这些 xml 计划here，以便我们查看详细信息。屏幕截图未显示所有计划详细信息。
@DanGuzman 感谢您的回复！ #1。我重新运行了我存储的查询 @link 。仍然“聚集索引”节点将“实际行”显示为 0 和 3，但不是 10。请告诉您是在 StackExchange 上还是以其他方式运行查询？ #2。执行计划@link#3。当研究 XML 计划时，在“RunTimeCountersPerThread”下，每个“线程”都有“ActualRows”。 ActualRows 的总和产生 10，布伦特的图形计划显示的是 10，但 StackExchange 没有显示。

标签： sql-server sql-like sql-execution-plan

【解决方案1】：

您的统计信息（确定要使用的索引以及可能读取的行数）已关闭。请不要设置一个工作来每小时或每天重建所有统计信息（这非常不必要并且可能很昂贵），而是通过以下方式重建该表上的统计信息：

update statistics schemaname.tablename with fullscan;

通常这会将查询计划与实际计划同步。在表上重建索引将更新所有统计信息，但这可能不是必需的。

要重建给定表上的所有索引，您可以发出：

ALTER INDEX ALL ON schemaname.tablename REBUILD;

这样做的好处是所有碎片都将得到解决，并且可以为该表提供最新的统计信息。在一张大桌子上，这可能需要一段时间。

【讨论】：

感谢您的回复！我看到此列上有可用的统计信息。 Query @link 和 Stats 也是最近的。