ต่อไปนี้เป็นย่อหน้าจากMicrosoft เอกสาร :
เพจใหม่ที่จัดสรรในฮีปโดยเป็นส่วนหนึ่งของการดำเนินการ DML จะไม่ใช้การบีบอัด PAGE จนกว่าฮีปจะถูกสร้างใหม่ สร้างฮีปอีกครั้งโดยการลบและการนำการบีบอัดมาใช้ใหม่หรือโดยการสร้างและลบดัชนีคลัสเตอร์
ฉันไม่สามารถเข้าใจได้ว่าทำไมถึงเป็นเช่นนี้ หากฉันมีฮีปที่มีการตั้งค่าการบีบอัดที่ระบุเหตุใดจึงไม่ใช้กับเพจที่เป็นของตาราง
ขอบคุณ
คำตอบ:
ในขณะที่ฉันไม่ทราบกลไกภายในเฉพาะที่รับผิดชอบความแตกต่างฉันสามารถพูดได้ว่า Heaps มีการจัดการ (ภายใน) แตกต่างจากดัชนีแบบคลัสเตอร์เล็กน้อย (และอาจเป็นดัชนีแบบไม่รวมกลุ่ม):
การลบแถวออกจากฮีปเพื่อให้เพจข้อมูลหนึ่งหน้าหรือมากกว่านั้นว่างเปล่า (ไม่มีแถวที่จัดสรร) ไม่จำเป็นต้องทำให้พื้นที่นั้นว่าง คุณอาจจะต้องสร้างและจากนั้นปล่อยดัชนีแบบ Clustered บนตารางหรือการโทรALTER TABLE [TableName] REBUILD;(ตั้งแต่ SQL Server 2014?) โปรดดูหน้าเอกสาร Microsoft สำหรับDELETEสำหรับรายละเอียดและตัวเลือกเพิ่มเติม
การแทรกแถวแต่ละแถว (เช่นไม่ใช่การตั้งค่าINSERT) ลงในฮีปจะไม่เติมหน้าข้อมูลให้ครบถ้วนเหมือนกับที่ใช้กับดัชนีแบบคลัสเตอร์ ดัชนีแบบกลุ่มจะพอดีกับแถวตราบใดที่มีพื้นที่ว่างสำหรับแถว (ข้อมูลและค่าใช้จ่ายในแถว) บวกกับค่าใช้จ่าย 2 ไบต์ของอาร์เรย์สล็อต อย่างไรก็ตามหน้าข้อมูลใน Heaps ไม่ได้ใช้จำนวนไบต์ที่เหลืออยู่บนหน้าเว็บ แต่ใช้ตัวบ่งชี้ทั่วไปที่แสดงว่าหน้าเต็มรูปแบบมากเพียงใดและไม่มีหลายระดับที่ถูกรายงาน ระดับต่าง ๆ ตามบรรทัดของ: 0%, 20%, 50%, 80% และเต็ม 100% และมันจะสลับไปเป็น 100% ในขณะที่ยังมีพื้นที่ว่างสำหรับแถวอื่น (และในความเป็นจริงมีการแทรกจำนวนแถวเดียวกันเหล่านั้นในการดำเนินการที่ตั้งค่าไว้แล้ว แน่นอนเช่นเดียวกับDELETE การดำเนินการการสร้างฮีปใหม่จะแพ็คแถวให้มากที่สุดเท่าที่จะพอดีกับหน้าข้อมูล
ตอนนี้ให้พิจารณาข้อมูลต่อไปนี้ซึ่งนำมาจากส่วน "เมื่อการบีบอัดหน้าเกิดขึ้น" ของหน้าเอกสาร Microsoft สำหรับการใช้การบีบอัดหน้า :
... เมื่อมีการเพิ่มข้อมูลในหน้าข้อมูลแรกข้อมูลจะถูกบีบอัดแถว ... เมื่อหน้าเต็มแถวถัดไปที่จะเพิ่มจะเริ่มต้นการดำเนินการบีบอัดหน้า มีการตรวจสอบหน้าทั้งหมด; ...
ดังนั้นดูเหมือนว่าทั้งหมดสอดคล้องกับพฤติกรรมฮีปอื่น ๆ ที่พวกเขาต้องการการแก้ไขตาราง REBUILD สร้าง / DROP ของดัชนีคลัสเตอร์หรือการเปลี่ยนแปลงในการตั้งค่าการบีบอัดข้อมูล (ทั้งหมดนี้สร้างฮีปใหม่) ก่อนที่จะเขียนหน้าข้อมูล ได้อย่างดีที่สุด หาก Heaps ไม่ได้รับการรู้แจ้งว่า "ทั้งหน้า" (จนกว่า Heap จะถูกสร้างขึ้นมาใหม่) และไม่รู้ว่าเมื่อใดที่เพจนั้นเต็มแน่นอนพวกเขาจะไม่รู้ว่าเมื่อใดที่จะเริ่มต้นการดำเนินการบีบอัดหน้าเว็บ แทรกแถว)
เทคนิคอื่นที่จะ จำกัด ฮีปบางส่วนจากการบีบอัดหน้าเว็บที่ใช้อัตโนมัติ (แม้ว่าจะทำได้) ก็คือการใช้การบีบอัดจะต้องใช้ดัชนีที่ไม่ได้ทำดัชนีทั้งหมดสำหรับฮีปนั้น (ถ้ามี) เพื่อสร้างใหม่ เนื่องจากหน้าที่เชื่อมโยงสำหรับ "การบีบอัดข้อมูล" ยังระบุด้วย:
การเปลี่ยนการตั้งค่าการบีบอัดของฮีปต้องใช้ดัชนีที่ไม่ใช่คลัสเตอร์ทั้งหมดในตารางเพื่อสร้างใหม่เพื่อให้มีพอยน์เตอร์ไปยังตำแหน่งแถวใหม่ในฮีป
"พอยน์เตอร์" ที่ถูกอ้างถึงคือ Row IDs (RIDs) ซึ่งประกอบด้วย: FileID, PageID และ slot / position บนหน้า RID เหล่านี้จะถูกคัดลอกไปยังดัชนีที่ไม่ได้เป็นคลัสเตอร์ ในฐานะที่เป็นตำแหน่งทางกายภาพที่แม่นยำบางครั้งพวกเขาจะทำการค้นหาได้เร็วกว่าการสำรวจทรี b-tree ด้วยปุ่มดัชนีแบบคลัสเตอร์ แต่ข้อเสียเปรียบประการหนึ่งของที่ตั้งทางกายภาพคือมันสามารถเปลี่ยนแปลงได้และนั่นเป็นปัญหาที่นี่ อย่างไรก็ตามดัชนีแบบคลัสเตอร์จะไม่ประสบปัญหานี้เนื่องจากค่าคีย์ของพวกเขาถูกคัดลอกไปยังดัชนีแบบไม่รวมกลุ่มเป็นตัวชี้กลับไปยังดัชนีแบบกลุ่ม และค่าคีย์ยังคงเหมือนเดิมแม้ว่าจะเปลี่ยนตำแหน่งทางกายภาพแล้วก็ตาม
ดูเพิ่มเติมที่:
ส่วน "การจัดการฮีป" ของหน้า Microsoft Docs สำหรับฮีป (ตารางที่ไม่มีดัชนีแบบคลัสเตอร์) :
เมื่อต้องการสร้างฮีปเพื่อเรียกคืนพื้นที่ที่สูญเปล่าให้สร้างดัชนีคลัสเตอร์บนฮีปแล้วปล่อยดัชนีคลัสเตอร์นั้น
ส่วน "ข้อควรพิจารณาเมื่อคุณใช้การบีบอัดแถวและหน้า" ของหน้าเอกสาร Microsoft สำหรับการบีบอัดข้อมูล :
เมื่อมีการกำหนดค่าฮีปสำหรับการบีบอัดระดับหน้าเพจจะได้รับการบีบอัดระดับหน้าด้วยวิธีต่อไปนี้เท่านั้น:
- ข้อมูลนำเข้าจำนวนมากโดยเปิดใช้งานการเพิ่มประสิทธิภาพจำนวนมาก
- ข้อมูลถูกแทรกโดยใช้ INSERT INTO ... WITH (TABLOCK) ไวยากรณ์และตารางไม่มีดัชนีที่ไม่เป็นคลัสเตอร์
- ตารางถูกสร้างใหม่โดยดำเนินการคำสั่ง ALTER TABLE ... REBUILD พร้อมกับตัวเลือกการบีบอัด PAGE
และข้อความที่ยกมาในคำถาม
ไม่ใช่ทุกกลไกใน SQL Server เหมือนที่เราเชื่อว่าควรเป็น
Paul Randal ได้ให้คำแนะนำที่ดีเกี่ยวกับการจัดการปัญหา
http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-2930-fixing-heap-fragmentation/