SQL：实际行数差异
可能的重复：
SQL Server 如何计算出估计的行数行？
我只是在查看SQL Server图形执行计划，遇到以下两个信息：
- 实际行数-2385
- 估计行数-180
我想知道为什么会出现这种差异。你能解释一下它们之间有什么区别吗？如果您能用一些例子进行解释，将会很有帮助。
谢谢。
Possible Duplicate:
How does SQL server work out the estimated number of rows?
I was just looking through SQL Server Graphical Execution plan and I encountered the following two information:
- actual number of rows-2385
- estimated number of rows-180
I was wondering why this difference was coming. Can you explain me what is the difference between them. It will be helpful if you can explain with some example.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
行估计基于统计数据。不准确的估计可能来自多种因素：
一般来说，不必担心直到出现问题为止。
根据我的经验，它通常基于统计数据中的基数。
如果您基于两个字段进行选择，这两个字段都有索引，则行估计将基于相应索引中值的可能性乘以总行数的乘积。
Row estimates are based on statistics. Inaccurate estimates can come from a number of factors:
As a rule, don't worry about it until you have issues.
I my experience, it's most often based on the cardinality in your stats.
If you are selecting based on two fields, both of which have indexes, the row estimate will be based on a product of the likelihood of the values in the respective indexes, times the total number of rows.
我对 SQL Server 不太了解，所以这是一个有根据的猜测：表中保存的统计数据与表中的实际数据之间存在差异。
数据库保存有关表的统计数据，优化器可以使用这些数据为要执行的 SQL 找到最佳（最便宜）的查询计划。这些统计数据包括例如总行数和跨列的数据分布（例如字段“性别”包含 60% 的值“m”和 40% 的值“f”）。您可能在这里看到的是统计信息已过时，因此优化器完成的计算不准确：优化器假定结果包含 180 行，但实际上（执行查询时）它返回 2385。尝试更新统计信息（不知道 SQL Server 中的确切语法）并看看这是否会改变数字。
I don't know SQL Server too much, so this is an educated guess: There is a discrepancy between the statistical data kept about the table and the actual data in the table.
Databases keep statistical data about tables, which can be used by the optimizer to find an optimal (least expensive) query plan for the SQL that you want to execute. Those statistics include for instance the total number of rows and the distribution of data across columns (for instance that the field 'gender' contains 60% values 'm' and 40% values 'f'). What your likely seeing here, is that the statistics are outdated and the calculations done by the optimizer hence inacurate: The optimizer assumed the result to contain 180 rows, in reality though (when executing the query) it returns 2385. Try updating the statistics (don't know the exact syntax in SQL server) and see if that changes the numbers.