sys.dm_db_partition_stats.row_count 在獲取每個表的 Azure SQL 數據庫行數時有多不准確？

Question

我已經看到了一些關於sys.dm_db_partition_stats.row_count如何由於提供對象的統計信息而不是實際執行COUNT()而產生不准確結果的一般性陳述。 但是，我從來沒有能夠找到這些陳述背后的任何更深層次的原因或驗證我的 Azure SQL DB 上的假設。

所以我想學習——

1. 這種方法實際上有多不准確？
2. 為什么結果可能會出現偏差？
   （例如統計數據每天只重新計算一次/在特定的 object 操作上）。

非常感謝任何相關的見解！

---

我能夠自己找出幾件事——主要是通過運行包含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 A.查詢GROUP BY A.schema_id, A.Name中的名稱或兩條具有相同table_name的記錄（如果您不使用GROUP BY ）

Answer 1

我們很高興您找到了解決方案並自己解決了它。 您的新版本應該是一個答案。 我只是幫助您將其發布為答案，這可能對其他社區成員有益：

我能夠自己找出幾件事——主要是通過運行包含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 A.查詢GROUP BY A.schema_id, A.Name中的名稱或兩條具有相同table_name的記錄（如果您不使用GROUP BY ）

再次感謝您的分享。

並感謝@conor 的 commnet：“如果你想看看數字有多遠，我建議你嘗試進行用戶事務，插入一堆行，然后回滾事務。”