Quelle est la précision de la colonne sys.partition.rows?

La vue système sys.partitionsa une colonne "lignes" qui est le nombre total de lignes dans une partition donnée. Pour une table qui n'est pas partitionnée (ou qui n'a qu'une seule partition selon la façon dont vous la regardez), cette colonne donne le nombre de lignes de la table.

Je suis curieux de savoir à quel point cette colonne est précise et si je peux l'utiliser au lieu d'un SELECT COUNT(1) FROM TableName. J'ai fait quelques expériences où créer une table et ajouter quelques milliers de lignes, supprimer quelques centaines, ajouter quelques milliers de plus, etc. et le compte a toujours été mort. Cependant, j'ai une table avec environ 700 lignes de mil et plusieurs index. La ligne sys.partitionsde l'index clusterisé est de nouveau morte, mais les autres indices montrent de légères variations (+ -20k).

Quelqu'un sait-il comment cette ligne est calculée et si elle est aussi précise qu'elle y paraît?

Books Online indique que le champ de lignes "indique le nombre approximatif de lignes dans cette partition." Je m'attendrais donc à ce qu'il soit proche, mais pas précis à 100%, 100% du temps.

Michael Zilberstein rapporte un exemple d' sys.partitionsêtre extrêmement incorrect dans À défaut d'un clou . Je ne dis pas que c'est un phénomène courant, mais c'est possible.

sys.dm_db_index_physical_statscontient un record_countchamp qui semble être plus précis, mais sachez que l'exécution du DMV peut entraîner un problème de blocage REDO si vous l'exécutez sur une instance hébergeant un réplica secondaire lisible AlwaysOn.

L' explication du record_countchamp affiche les informations suivantes:

Nombre total d'enregistrements.

Pour un index, le nombre total d'enregistrements s'applique au niveau actuel de l'arborescence b dans l'unité d'allocation IN_ROW_DATA.

Pour un segment de mémoire, le nombre total d'enregistrements dans l'unité d'allocation IN_ROW_DATA.

Pour un segment, le nombre d'enregistrements renvoyés par cette fonction peut ne pas correspondre au nombre de lignes renvoyées en exécutant un SELECT COUNT (*) sur le segment. En effet, une ligne peut contenir plusieurs enregistrements. Par exemple, dans certaines situations de mise à jour, une seule ligne de segment de mémoire peut avoir un enregistrement de transfert et un enregistrement transféré à la suite de l'opération de mise à jour. De plus, la plupart des grandes lignes LOB sont divisées en plusieurs enregistrements dans le stockage LOB_DATA. Pour les unités d'allocation LOB_DATA ou ROW_OVERFLOW_DATA, le nombre total d'enregistrements dans l'unité d'allocation complète.

Voir aussi la réponse de Martin Smith à une question similaire sur Stack Overflow.