sys.partition.rows列的准确性如何？

系统视图sys.partitions具有“行”列，该列是给定分区中的总行数。对于未分区的表（或者只有一个分区，这取决于您的外观），此列给出了表中的行数。

我很好奇此列的准确性，以及是否可以使用它代替SELECT COUNT(1) FROM TableName。我做过一些实验，创建一个表并添加几千行，删除几百行，再添加几千个，等等，而且这种情况一直没有解决。但是，我有一张表，约有7亿行和几个索引。sys.partitions聚簇索引的行再次停滞不前，但是其他索引显示出一些细微的变化（+ -20k）。

有谁知道该行的计算方式以及它的准确性是否与所显示的相同？

联机丛书指出，行字段“指示此分区中的大约行数”。因此，我希望它在100％的时间内接近，但不是100％准确。

迈克尔•齐伯斯坦（Michael Zilberstein）报道了一个“缺钉”的sys.partitions错误例子。并不是说这是普遍现象，但是有可能。

sys.dm_db_index_physical_stats包含一个record_count看起来更准确的字段，尽管请注意，如果在承载AlwaysOn可读辅助副本的实例上运行DMV可能会导致REDO阻止问题。

该解释的record_count字段显示以下信息：

记录总数。

对于索引，记录总数适用于IN_ROW_DATA分配单元中b树的当前级别。

对于堆，是IN_ROW_DATA分配单元中的记录总数。

对于堆，此函数返回的记录数可能与通过对堆运行SELECT COUNT（*）返回的行数不匹配。这是因为一行可能包含多个记录。例如，在某些更新情况下，由于更新操作，单个堆行可能具有转发记录和转发记录。同样，大多数大的LOB行在LOB_DATA存储中被拆分为多个记录。对于LOB_DATA或ROW_OVERFLOW_DATA分配单位，完整分配单位中的记录总数。

另请参阅Martin Smith对Stack Overflow中类似问题的回答。