1

我已经看到了一些关于sys.dm_db_partition_stats.row_count由于提供对象的统计信息而不是实际执行COUNT(). 但是，我从未能够找到这些陈述背后的任何更深层次的原因，也无法在我的 Azure SQL DB 上验证假设。

所以我想学习——

  1. 这种方法 实际上有多不准确 ？
  2. 为什么结果可能会出现偏差？
    （例如，统计数据仅每天重新计算一次/针对特定对象操作）。

非常感谢任何相关的见解！


我能够自己找出几件事——主要是通过运行各种包含 的查询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）

4

1 回答 1

2

我们很高兴您找到了解决方案并自己解决了它。您的新版本应该是一个答案。我只是帮助您将其发布为答案，这可能对其他社区成员有益：

我能够自己找出几件事——主要是通过运行各种包含 的查询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）

再次感谢您的分享。

并感谢@conor 的 commnet：“如果你想看看数字有多远，我建议你尝试进行用户事务，插入一堆行，然后回滚事务。”

于 2020-07-30T01:20:25.877 回答