在获取每个表的Azure SQL db行计数时，sys.dm_db_分区_stats.row_计数有多不准确？

我已经看到了一些关于sys.dm_db_partition_stats.row_count如何由于提供对象的统计信息而不是实际进行计数而产生不准确结果的一般性语句。然而，我一直无法找到这些语句背后的任何更深层次的原因，也无法在我的Azure SQL DB上验证这一假设。

所以我想学习-

这个方法到底有多不准确？ 为什么结果可能会有偏差？e、 g.统计数据每天只重新计算一次/针对特定对象操作。 任何相关的见解都将不胜感激！

有几件事是我自己能够发现的——主要是通过运行包含sys.dm_db_partition_stats.row_count的各种查询，同时知道每个表中的实际行数。

这是我提出的最后一个问题 在我的例子中，每个表的行数都很快且准确，从高计数到低计数排序。

选择 SCHEMA_NAMEA.SCHEMA_id+'.+A.Name作为表_Name， B.对象id、B.索引id、B.行计数 从…起 sys.dm_db_分区_统计数据B 左连接 系统对象A 在A.object\u id=B.object\u id上 哪里 SCHEMA_NAMEA.SCHEMA_id“sys” 和B.index_id='0'或B.index_id='1' 订购人 B.行数说明 WHERE子句的第一行用于排除系统表，例如sys.plan\u persist\u wait\u stats和许多其他表

第二行处理非唯一的非聚集索引，这些索引是对象，显然有自己的统计数据->如果不过滤它们，则在查询输出中使用GROUP BY A.schema_id、A.Name或两条具有相同表名的记录（如果不使用GROUP BY）时，索引表的行数将加倍

---

我们很高兴您找到了解决方案并自己解决了。你的新版本应该是一个答案。我只是帮你把它贴出来作为答案，这对其他社区成员是有益的：

有几件事是我自己能够发现的——主要是通过运行包含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\u persist\u wait\u stats和许多其他表

第二行处理非唯一的非聚集索引，这些索引是对象，显然有自己的统计数据->如果不过滤它们，则在查询输出中使用GROUP BY A.schema_id、A.Name或两条具有相同表名的记录（如果不使用GROUP BY）时，索引表的行数将加倍

再次感谢您的分享

---

感谢@conor的commnet：如果你想知道数字之间的距离，我建议你尝试进行用户事务，插入一组行，然后回滚事务。

如果你想知道数字之间的距离，我建议你尝试进行用户事务，插入一组行，然后回滚事务。您好@Dima，您应该将您的新编辑作为答案发布。@Conor，谢谢！这实际上帮助了我。在我的例子中，数据库每天更新的次数不超过几次，因此我可以忍受统计数据的微小差异。行数可以在某些时间点产生。在话题之外，我很高兴看到MS Architect对我的问题发表了评论：感谢您花时间做这件事。请注意，如果您不重建索引等，计数可能永远是错误的。这是近似值，可以完全正确，但不能保证是正确的。谢谢@Leon！我不确定你提到的是哪一个编辑，因为，事实上，这是我在原始问题中发布的内容的一部分，只是对段落进行了重新排序，使其自上而下。另外，请务必包含Conor的评论—要执行一些用户事务，请插入一组行，然后回滚事务—以便确定stats.row\u count的不一致程度