估计行数与实际行数，对性能有何影响？
Estimate Rows vs Actual Rows, what is the impact on performance?
我有一个执行速度非常快的查询，但在生产环境中，当服务器负载很高时，它的性能却不尽人意。我怀疑可能是执行计划中的估计行数远低于实际行数。我知道服务器统计数据不会过时。
我现在正在优化一个新查询，我担心它在生产中会出现同样的问题。行数 returned 和 CPU 以及读取都在我的数据管理员要求的指定阈值之内。正如您在上面的 SQL Sentry 计划中看到的那样，有一些临时表估计单行但 return 100 倍的行。
我的问题是，即使行数很少，如此大的行数差异是否会导致服务器性能瓶颈？第二个问题，如果问题不是糟糕的缓存计划或陈旧的统计数据，还有哪些其他问题会导致计划显示这种差异？
实际行数和估计行数之间的差异不会导致服务器中出现 "bottleneck"。
影响在于查询的算法和资源分配。 SQL 服务器有多种算法，可用于 JOIN 和 GROUP BY 等操作。数据的（估计）大小是用于选择适当算法的主要信息之一。
选择错误的算法并不完全是瓶颈，但它确实会减慢查询速度。您需要研究执行计划，看看您的情况是否会发生这种情况。
如果您有来自单个 table 的 select 的简单查询，那么执行计划的选项就会少很多。在这种情况下，我很容易想到的唯一影响是使用完整的 table 扫描而不是索引进行过滤。对于您的数据大小，我认为这不会产生太大影响。
Estimate Rows vs Actual Rows, what is the impact on performance?
如果 Estimate Rows 和 Actual Rows 之间存在巨大差异，那么您需要担心该查询。
这不可能是没有原因的。
- 过时的统计数据
- 倾斜的数据分布：这里更新了统计数据，但它是 skewed.Create 那些索引的过滤统计数据会有所帮助。
- 取消优化查询：写得不好 query.Join 条件错误。
我有一个执行速度非常快的查询，但在生产环境中，当服务器负载很高时，它的性能却不尽人意。我怀疑可能是执行计划中的估计行数远低于实际行数。我知道服务器统计数据不会过时。
我现在正在优化一个新查询，我担心它在生产中会出现同样的问题。行数 returned 和 CPU 以及读取都在我的数据管理员要求的指定阈值之内。正如您在上面的 SQL Sentry 计划中看到的那样，有一些临时表估计单行但 return 100 倍的行。
我的问题是，即使行数很少，如此大的行数差异是否会导致服务器性能瓶颈？第二个问题，如果问题不是糟糕的缓存计划或陈旧的统计数据，还有哪些其他问题会导致计划显示这种差异？
实际行数和估计行数之间的差异不会导致服务器中出现 "bottleneck"。
影响在于查询的算法和资源分配。 SQL 服务器有多种算法，可用于 JOIN 和 GROUP BY 等操作。数据的（估计）大小是用于选择适当算法的主要信息之一。
选择错误的算法并不完全是瓶颈，但它确实会减慢查询速度。您需要研究执行计划，看看您的情况是否会发生这种情况。
如果您有来自单个 table 的 select 的简单查询，那么执行计划的选项就会少很多。在这种情况下，我很容易想到的唯一影响是使用完整的 table 扫描而不是索引进行过滤。对于您的数据大小，我认为这不会产生太大影响。
Estimate Rows vs Actual Rows, what is the impact on performance?
如果 Estimate Rows 和 Actual Rows 之间存在巨大差异，那么您需要担心该查询。
这不可能是没有原因的。
- 过时的统计数据
- 倾斜的数据分布：这里更新了统计数据，但它是 skewed.Create 那些索引的过滤统计数据会有所帮助。
- 取消优化查询：写得不好 query.Join 条件错误。