คอลัมน์ sys.partition.rows มีความแม่นยำเพียงใด

มุมมองระบบsys.partitionsมีคอลัมน์ "แถว" ที่เป็นจำนวนแถวทั้งหมดในพาร์ติชันที่กำหนด สำหรับตารางที่ไม่ได้แบ่งพาร์ติชัน (หรือมีพาร์ติชันเดียวขึ้นอยู่กับวิธีที่คุณดู) คอลัมน์นี้ให้จำนวนแถวในตาราง

SELECT COUNT(1) FROM TableNameฉันอยากรู้วิธีที่ถูกต้องคือคอลัมน์นี้และถ้าผมสามารถใช้มันแทน ฉันได้ทำการทดลองที่สร้างตารางและเพิ่มสองสามพันแถวลบสองสามร้อยเพิ่มอีกสองสามพัน ฯลฯ และจำนวนนั้นตายเสมอ อย่างไรก็ตามฉันมีตารางหนึ่งตารางที่มีประมาณ 700 ล้านแถวและดัชนีหลายรายการ แถวในsys.partitionsสำหรับดัชนีคลัสเตอร์นั้นตายไปแล้วอีกครั้งอย่างไรก็ตามดัชนีอื่น ๆ แสดงความแตกต่างเล็กน้อย (+ -20k)

ไม่มีใครรู้วิธีคำนวณแถวนี้และถ้ามันถูกต้องตามที่ปรากฏ?

Books Online ระบุว่าฟิลด์แถว "ระบุจำนวนแถวโดยประมาณในพาร์ติชันนี้" ฉันคาดหวังว่ามันจะปิด แต่ไม่ถูกต้อง 100%, 100% ของเวลา

รายงานไมเคิล Zilberstein ตัวอย่างของsys.partitionsการเป็นลำพองไม่ถูกต้องในสำหรับต้องการของเล็บ ไม่ได้บอกว่ามันเป็นเรื่องธรรมดา แต่ก็เป็นไปได้

sys.dm_db_index_physical_statsมีrecord_countเขตข้อมูลที่ดูเหมือนจะแม่นยำยิ่งขึ้นแม้ว่าจะทราบว่าการใช้ DMV อาจส่งผลให้เกิดปัญหาการบล็อก REDO หากคุณเรียกใช้บนอินสแตนซ์ที่โฮสต์ AlwaysOn Readable Secondary Replica

คำอธิบายสำหรับrecord_countข้อมูลแสดงให้เห็นว่าข้อมูลต่อไปนี้:

จำนวนเร็กคอร์ดทั้งหมด

สำหรับดัชนีจำนวนเร็กคอร์ดทั้งหมดนำไปใช้กับระดับปัจจุบันของ b-tree ในหน่วยการจัดสรร IN_ROW_DATA

สำหรับฮีปจำนวนรวมของเร็กคอร์ดในหน่วยการจัดสรร IN_ROW_DATA

สำหรับฮีปจำนวนของเร็กคอร์ดที่ส่งคืนจากฟังก์ชันนี้อาจไม่ตรงกับจำนวนแถวที่ส่งคืนโดยการรัน SELECT COUNT (*) กับฮีป นี่เป็นเพราะแถวอาจมีหลายระเบียน ตัวอย่างเช่นในบางสถานการณ์การอัพเดตแถวฮีปเดียวอาจมีเร็กคอร์ดการส่งต่อและเร็กคอร์ดที่ส่งต่อซึ่งเป็นผลมาจากการดำเนินการอัพเดต นอกจากนี้แถว LOB ขนาดใหญ่ส่วนใหญ่จะแบ่งออกเป็นหลายระเบียนในหน่วยเก็บข้อมูล LOB_DATA สำหรับหน่วยการจัดสรร LOB_DATA หรือ ROW_OVERFLOW_DATA จำนวนเร็กคอร์ดทั้งหมดในหน่วยการจัดสรรที่สมบูรณ์

ดูคำตอบของ Martin Smithสำหรับคำถามที่คล้ายกันใน Stack Overflow