sys.partition.rows列はどれくらい正確ですか？

システムビューにsys.partitionsは、特定のパーティション内の行の総数である「行」列があります。パーティション化されていない（または見方によってはパーティションが1つしかない）テーブルの場合、この列はテーブル内の行数を示します。

私はこの列がどれほど正確か、そしての代わりにそれを使用できるかどうかに興味がありSELECT COUNT(1) FROM TableNameます。テーブルを作成して数千行を追加し、数百を削除し、さらに数千を追加するなど、いくつかの実験を行いましたが、カウントは常に無効になっています。ただし、約700ミリ行と複数のインデックスを持つ1つのテーブルがあります。sys.partitionsクラスター化インデックスの行は再び無効になりますが、他のインデックスにはわずかな変動（+ -20k）が見られます。

この行がどのように計算され、表示されるのと同じくらい正確かどうかは誰にもわかりますか？

Books Onlineでは、rowsフィールドは「このパーティションのおよその行数を示しています」と述べています。したがって、100％正確ではなく、100％近い時間になると予想します。

マイケルジルバースタインは爪の欠乏sys.partitionsで乱暴に間違っている例を報告します。よくあることではありませんが、可能です。

sys.dm_db_index_physical_statsrecord_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の回答も参照してください。