ฉันควรเพิ่มการบีบอัดระดับหน้าก่อนเพิ่มคีย์หลักหรือหลังจาก?

14

สถานการณ์

คลังข้อมูลบน SQL Server 2008 Enterprise
ฮีปของแถว 36+ ล้านแถว (ไม่ต้องถาม) พร้อมคอลัมน์มากกว่า 60 คอลัมน์
เพิ่มขึ้น 750k ต่อเดือน
ไม่ได้กำหนดคีย์หลัก (ตอนนี้ฉันระบุแล้ว)
ไม่มีการบีบอัด

สิ่งที่ฉันกำลังคิดที่จะทำ (ตามลำดับนี้)

เพิ่มการบีบอัดระดับหน้า
เพิ่ม PK
เพิ่มดัชนีที่ไม่ทำคลัสเตอร์จำนวนหนึ่ง
ทำสิ่งนี้ให้เร็วที่สุด

คำถาม

ท้ายที่สุด: ฉันจะเพิ่มการบีบอัด PK หรือหน้าก่อนหรือไม่ (มันสำคัญไหม)
ถ้าฉันเพิ่มการบีบอัดก่อนลงในตารางดัชนีใด ๆ จะสืบทอดการตั้งค่าการบีบอัดระดับตารางหรือไม่ คำตอบสำหรับคำถามนี้คือ "ไม่บีบอัดไม่ได้รับมรดก" พบได้ที่นี่ใน dba.stackexchange

สิ่งที่ฉันกำลังโน้มตัวไปข้างหน้าในขณะนี้

-- Add page level compression
alter table     dbo.TableName
rebuild with    (data_compression = page)
; 
go

-- Add primary key
alter table             dbo.TableName
add constraint          PK_TableName
primary key clustered   (<Columns>)
;
go

-- Add NC_IXs here
...
...

ฉันได้ดูที่นี่ (เอกสารการสร้าง PK)และที่นี่ (เอกสาร ALTER TABLE)แต่ไม่สามารถเห็นอะไรที่ชัดเจนเกี่ยวกับดัชนีที่สืบทอดการตั้งค่าการบีบอัดตารางหรือไม่ คำตอบสำหรับคำถามนี้คือ "ไม่บีบอัดไม่ได้รับมรดก" พบได้ที่นี่ใน dba.stackexchange

sql-server sql-server-2008

— Adrian Torrie
แหล่งที่มา

12

ดัชนีคลัสเตอร์เป็นจริงตาราง บนสมมติฐานที่ว่าคีย์หลักของคุณเป็นคลัสเตอร์จากนั้นฉันจะสร้างคีย์หลักแบบคลัสเตอร์ที่มีการบีบอัดระดับหน้าแทนที่จะพยายามทำสองขั้นตอน

-- Add primary key
ALTER TABLE             dbo.TableName
ADD CONSTRAINT          PK_TableName
PRIMARY KEY CLUSTERED   (<Columns>)
WITH (DATA_COMPRESSION = PAGE)
;

ฉันจะคัดลอกแถวประมาณ 100k ไปยังตารางชั่วคราว (ชั่วคราวทางกายภาพไม่ใช่ # ชั่วคราว) และเรียกใช้การทดสอบบางอย่าง ลองเรียกใช้การบีบอัดก่อนคีย์คลัสเตอร์แรกก่อนลองทำตามขั้นตอนเดียว ดูว่าอะไรทำงานได้เร็วที่สุด ฉันเดาว่ามันจะเป็นขั้นตอนเดียวเป็นการส่วนตัว :)

— Kenneth Fisher
แหล่งที่มา

2

การบีบอัดหน้าจะสลับข้อมูลเป็นจำนวนมาก ฉันคาดว่าจะทำการบีบอัดก่อนจะส่งผลให้ I / O โดยรวมน้อยลงเนื่องจากการดำเนินการทำคลัสเตอร์จะอ่านหน้าเว็บที่บีบอัด

— แม็กซ์เวอร์นอน
แหล่งที่มา