sys.partition.rows 열은 얼마나 정확합니까?


13

시스템보기 sys.partitions에는 주어진 파티션의 총 행 수인 "행"열이 있습니다. 분할되지 않은 (또는 보는 방식에 따라 하나의 파티션 만있는) 테이블의 경우이 열은 테이블의 행 수를 나타냅니다.

이 열이 얼마나 정확한지 궁금하고 대신 열을 사용할 수 있는지 궁금합니다 SELECT COUNT(1) FROM TableName. 나는 테이블을 만들고 수천 행을 추가하고, 몇 백을 삭제하고, 수천을 더 추가하는 몇 가지 실험을 해왔으며 카운트는 항상 죽었습니다. 그러나 약 700 mil 행과 여러 인덱스가있는 하나의 테이블이 있습니다. sys.partitions클러스터형 인덱스 의 행 이 다시 종료되었지만 다른 인덱스는 약간의 변동 (+ -20k)을 나타냅니다.

누구 든지이 행이 계산되는 방법을 알고 있습니까?


4
나는 지금 연령대의 행 열을 기반으로 쿼리 를 사용하고 있습니다 . 날짜가
지난

답변:


13

온라인 설명서에 따르면 행 필드는 " 이 파티션 의 대략적인 행 수를 나타냅니다 ." 따라서 100 % 정확하지는 않지만 100 % 정확할 것으로 예상합니다.

Michael Zilberstein sys.partitionsFor want to a nail 에서 극도로 잘못된 사례를보고합니다 . 그것이 흔한 일이라고 말하지는 않지만 가능합니다.

sys.dm_db_index_physical_statsrecord_countDMV를 실행하면 AlwaysOn 읽기 가능한 보조 복제본을 호스팅하는 인스턴스에서 DMV를 실행할 경우 REDO 차단 문제가 발생할 수 있음을 알고 있지만 더 정확한 것으로 보이는 필드가 포함되어 있습니다 .

설명 에 대한 record_count필드는 다음과 같은 정보를 보여줍니다

총 레코드 수

인덱스의 경우, 총 레코드 수는 IN_ROW_DATA 할당 단위에서 b- 트리의 현재 레벨에 적용됩니다.

힙의 경우 IN_ROW_DATA 할당 단위의 총 레코드 수입니다.

힙의 경우이 함수에서 리턴 된 레코드 수가 힙에 대해 SELECT COUNT (*)를 실행하여 리턴 된 행 수와 일치하지 않을 수 있습니다. 행에 여러 레코드가 포함될 수 있기 때문입니다. 예를 들어, 일부 업데이트 상황에서 단일 힙 행에는 업데이트 작업의 결과로 전달 레코드와 전달 된 레코드가있을 수 있습니다. 또한 대부분의 큰 LOB 행은 LOB_DATA 스토리지의 여러 레코드로 분할됩니다. LOB_DATA 또는 ROW_OVERFLOW_DATA 할당 단위의 경우 전체 할당 단위의 총 레코드 수입니다.

Stack Overflow에 대한 비슷한 질문에 대한 Martin Smith의 답변 도 참조하십시오 .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.