我看到了一些关于 sys.dm_db_partition_stats.row_count 由于提供对象的统计信息而不是实际执行 COUNT() . 然而，我始终无法在这些语句背后找到任何更深层次的原因，也无法在我的azuresqldb上验证这个假设。
所以我想学习-
这个方法到底有多不准确？
为什么结果会有偏差？
（例如，统计数据每天只重新计算一次/针对特定对象操作）。
任何相关的见解都将不胜感激！
有几件事是我自己能够发现的——主要是通过运行包含 sys.dm_db_partition_stats.row_count ，同时知道每个表中的实际行数。
这是我提出的最后一个问题
在我的例子中，每个表的行数都很快而且准确，从高到低排序。
SELECT
(SCHEMA_NAME(A.schema_id) + '.' + A.Name) as table_name,
B.object_id, B.index_id, B.row_count
FROM
sys.dm_db_partition_stats B
LEFT JOIN
sys.objects A
ON A.object_id = B.object_id
WHERE
SCHEMA_NAME(A.schema_id) <> 'sys'
AND (B.index_id = '0' OR B.index_id = '1')
ORDER BY
B.row_count DESC第一线 WHERE 子句用于排除系统表，例如。 sys.plan_persist_wait_stats 还有很多其他的。
第二行处理非唯一的非聚集索引（它们是对象，显然有自己的统计数据）->如果不将它们过滤掉，则在使用 GROUP BY A.schema_id, A.Name 或者两张相同的唱片 table_name 在查询输出中（如果不使用 GROUP BY )
1条答案
按热度按时间vnzz0bqm1#
我们很高兴你找到了解决办法，自己解决了。你的新版本应该是一个答案。我只是帮你把它作为答案贴出来，这对其他社区成员是有益的：
有几件事是我自己能够发现的——主要是通过运行包含
sys.dm_db_partition_stats.row_count，同时知道每个表中的实际行数。这是我提出的最后一个查询，它可以快速（在我的例子中）获得每个表的准确行数，从高计数到低计数排序。
第一线
WHERE子句用于排除系统表，例如sys.plan\u persist\u wait\u stats和其他许多表。第二行处理非唯一的非聚集索引（它们是对象，显然有自己的统计数据）->如果不将它们过滤掉，则在使用
GROUP BY A.schema_id, A.Name或者两张相同的唱片table_name在查询输出中（如果不使用GROUP BY)再次感谢您的分享。
感谢@conor的commnet：“如果你想知道这些数字有多远，我建议你尝试做用户事务，插入一堆行，然后回滚事务。”