Jak dokładna jest kolumna sys.partition.rows?

Widok systemu sys.partitionsma kolumnę „wiersze”, czyli całkowitą liczbę wierszy w danej partycji. W przypadku tabeli, która nie jest podzielona na partycje (lub ma tylko jedną partycję, w zależności od tego, jak na nią patrzysz), ta kolumna podaje liczbę wierszy w tabeli.

Jestem ciekawy, jak dokładna jest ta kolumna i czy mogę jej użyć zamiast SELECT COUNT(1) FROM TableName. Przeprowadziłem kilka eksperymentów, w których utworzyłem tabelę i dodałem kilka tysięcy wierszy, usunąłem kilkaset, dodałem kilka tysięcy więcej itd., A liczenie zawsze było martwe. Mam jednak jedną tabelę z około 700 milionami wierszy i kilkoma indeksami. Wiersz sys.partitionsdla indeksu klastrowanego znów jest martwy, jednak inne indeksy wykazują pewne niewielkie różnice (+ -20 tys.).

Czy ktoś wie, jak ten wiersz jest obliczany i czy jest tak dokładny, jak się wydaje?

Books Online stwierdza, że ​​pole wierszy „wskazuje przybliżoną liczbę wierszy na tej partycji”. Spodziewałbym się zatem, że będzie blisko, ale nie w 100% dokładny, w 100% przypadków.

Michael Zilberstein podaje przykład sys.partitionsbycia bardzo niepoprawnym w „Brak gwoździa” . Nie mówię, że jest to częste zjawisko, ale jest możliwe.

sys.dm_db_index_physical_statszawiera record_countpole, które wydaje się być dokładniejsze, choć należy pamiętać, że uruchomienie DMV może spowodować problem z blokowaniem REDO, jeśli uruchomisz go na instancji, na której znajduje się replika wtórna zawsze czytelna.

Wyjaśnienie na record_countpolu wyświetlane są następujące informacje:

Całkowita liczba rekordów.

W przypadku indeksu całkowita liczba rekordów dotyczy bieżącego poziomu b-drzewa w jednostce alokacji IN_ROW_DATA.

Dla sterty łączna liczba rekordów w jednostce alokacji IN_ROW_DATA.

W przypadku sterty liczba rekordów zwróconych z tej funkcji może nie być zgodna z liczbą wierszy zwracanych przez uruchomienie instrukcji SELECT COUNT (*) w stosunku do sterty. Wynika to z faktu, że wiersz może zawierać wiele rekordów. Na przykład w niektórych sytuacjach aktualizacji pojedynczy wiersz sterty może mieć rekord przekazywania i rekord przekazywany w wyniku operacji aktualizacji. Ponadto większość dużych wierszy LOB jest podzielonych na wiele rekordów w pamięci LOB_DATA. W przypadku jednostek alokacji LOB_DATA lub ROW_OVERFLOW_DATA całkowita liczba rekordów w pełnej jednostce alokacji.

Zobacz także odpowiedź Martina Smitha na podobne pytanie dotyczące przepełnienia stosu.

BOL rzeczywiście mówi dla tej kolumny „wskazuje przybliżoną liczbę wierszy w tej partycji”. A przybliżenie jest bardzo przybliżone. Widziałem już, że na pewnej partycji miałem 1 rekord. sy.partitions.rows wskazywał 4048 wierszy. Po usunięciu tego rekordu nadal wskazywał 4048 wierszy, nawet po przebudowaniu wszystkich indeksów itp. Jednym z wniosków jest to, że jeśli chcesz na nim polegać, nie rób tego.