MVCC และสาเหตุของข้อมูลบวม
ทำความเข้าใจการควบคุมการทำงานพร้อมกันหลายเวอร์ชัน เหตุผลที่ทูเพิลที่ตายแล้วสะสม และสาเหตุที่ธุรกรรมระยะยาวทำให้ข้อมูลบวม
MVCC และสาเหตุของข้อมูลบวม เป็นบทเรียน SQL Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน SQL Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส SQL Academy มีบทเรียนทั้งหมด 4 บทเรียน
MVCC คืออะไร
การควบคุมภาวะพร้อมกันหลายเวอร์ชัน แทนที่จะใช้การล็อก PostgreSQL จะเก็บแถวไว้หลายเวอร์ชัน ผู้อ่านจะเห็นภาพรวมที่สอดคล้องกัน ส่วนผู้เขียนจะสร้างเวอร์ชันใหม่โดยไม่บล็อกผู้อ่าน
การทำงานของ UPDATE
UPDATE ไม่ได้เปลี่ยนแถวเดิมโดยตรง:
- ทำเครื่องหมายเวอร์ชันเก่าของแถวว่า “ตายแล้ว” ที่ทรานแซกชัน T
- เขียนเวอร์ชันใหม่
- ทรานแซกชันอื่นจะเห็นเวอร์ชันใดก็ตามที่ภาพรวมของตนอนุญาต
เหตุใดจึงเกิดพื้นที่รก
เวอร์ชันที่ตายแล้วจะสะสมเพิ่มขึ้น ตารางจึงมีขนาดใหญ่ขึ้นแม้จำนวนแถวจะคงที่ หากไม่ทำความสะอาด คิวรีจะต้องสแกนแถวที่ตายแล้วเพิ่มขึ้นเรื่อย ๆ
เมื่อ VACUUM เรียกคืนพื้นที่
VACUUM ทำเครื่องหมายแถวที่ตายแล้วให้สามารถนำกลับมาใช้ได้ (ภายในไฟล์ตาราง) แต่จะไม่ลดขนาดไฟล์ เว้นแต่ไฟล์จะว่างทั้งหมดที่ส่วนท้าย VACUUM FULL จะเขียนตารางใหม่ ซึ่งต้องใช้การล็อกแบบพิเศษและทำงานช้า
Autovacuum
PostgreSQL เรียกใช้ autovacuum อยู่เบื้องหลัง โดยจะเริ่มทำงานเมื่อจำนวนแถวที่ตายแล้วเกินค่าขีดจำกัด:
autovacuum_vacuum_threshold = 50
autovacuum_vacuum_scale_factor = 0.2
-- vacuum when dead_rows > 50 + 0.2 * total_rowsภาระงานที่ทำให้เกิดพื้นที่รก
- การทำ UPDATE จำนวนมากบนตารางขนาดเล็ก / ตารางที่มีการใช้งานสูง
- การทำ DELETE เป็นชุดขนาดใหญ่ (ต้องใช้ vacuum เพื่อคืนพื้นที่)
- ทรานแซกชันที่ทำงานเป็นเวลานานขัดขวาง vacuum (ยึดภาพรวมไว้)
- เซสชันที่ค้างอยู่ในทรานแซกชันสะสมแถวที่ตายแล้วบนตารางที่มีการใช้งานสูง
การวินิจฉัยพื้นที่รก
ส่วนขยาย pgstattuple ให้ตัวเลขที่แม่นยำ:
CREATE EXTENSION pgstattuple;
SELECT * FROM pgstattuple('orders');
-- table_len, tuple_count, dead_tuple_count, free_space, etc.
SELECT * FROM pgstatindex('orders_user_id_idx');ทรานแซกชันที่ทำงานนานขัดขวาง Vacuum
VACUUM สามารถทำความสะอาดได้เฉพาะแถวที่เก่ากว่าทรานแซกชันที่ยังทำงานอยู่นานที่สุด เซสชันที่ค้างอยู่ในทรานแซกชันเป็นเวลา 4 ชั่วโมงหมายถึงมีแถวที่ตายแล้วซึ่งยังไม่ได้เรียกคืนเป็นเวลา 4 ชั่วโมง
SELECT pid, state, xact_start, NOW() - xact_start AS duration
FROM pg_stat_activity
WHERE state IN ('active', 'idle in transaction')
ORDER BY duration DESC NULLS LAST;การป้องกันการวนรอบ
รหัสทรานแซกชันมีขนาด 32 บิต หาก autovacuum ทำงานไม่ทัน คลัสเตอร์จะเผชิญ “การวนรอบ” และเข้าสู่โหมดปลอดภัย (บังคับใช้ VACUUM) โปรดตรวจสอบ:
SELECT datname, age(datfrozenxid) FROM pg_database
ORDER BY age(datfrozenxid) DESC;การลบเชิงตรรกะ ≠ การลบทางกายภาพ
DELETE ทำเครื่องหมายแถวว่าตายแล้ว พื้นที่จะเรียกคืนได้ด้วย VACUUM เท่านั้น การทำ DELETE จำนวนมากแล้วไม่ทำ vacuum จะทิ้งกลุ่มแถวที่ตายแล้วขนาดใหญ่ไว้
การอัปเดตแบบ HOT
หากคุณอัปเดตเฉพาะคอลัมน์ที่ไม่มีดัชนี และมีพื้นที่ว่างอยู่ในหน้าเดียวกัน PostgreSQL จะทำการอัปเดตแบบ HOT (ทูเพิลที่อยู่บนฮีปเท่านั้น) ซึ่งไม่ต้องแก้ไขดัชนีและทำให้เกิดพื้นที่รกน้อยลง
การลดพื้นที่รก
- ทำให้ธุรกรรมมีระยะเวลาสั้น
- หลีกเลี่ยง UPDATE แบบกว้างกับคอลัมน์ที่มีดัชนี (HOT อาจทำงานไม่ได้)
- ปรับแต่ง autovacuum ให้ทำงานเชิงรุกกับตารางที่มีการใช้งานสูง
- ใช้ pg_repack เพื่อเขียนตารางใหม่โดยไม่ต้องล็อกเป็นเวลานาน
สรุปทบทวน
MVCC ช่วยให้ทำงานพร้อมกันได้ แต่ต้องแลกกับการสะสมของแถวที่ไม่ใช้งาน
- VACUUM ทำความสะอาดแถวที่ไม่ใช้งาน
- Autovacuum เป็นสิ่งจำเป็น — อย่าปิดใช้งาน
- ธุรกรรมที่ทำงานนานจะขัดขวางการทำความสะอาด
- วินิจฉัยด้วย pgstattuple
ตรวจสอบอย่างรวดเร็ว
เหตุใด UPDATE จึงไม่ทำให้ตารางมีขนาดเล็กลง แม้จะเปลี่ยนเพียงคอลัมน์เดียว
คำถามที่พบบ่อย
บทเรียน “MVCC และสาเหตุของข้อมูลบวม” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “MVCC และสาเหตุของข้อมูลบวม” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส SQL Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส SQL Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “MVCC และสาเหตุของข้อมูลบวม”
ทำความเข้าใจการควบคุมการทำงานพร้อมกันหลายเวอร์ชัน เหตุผลที่ทูเพิลที่ตายแล้วสะสม และสาเหตุที่ธุรกรรมระยะยาวทำให้ข้อมูลบวม คุณปฏิบัติ SQL Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน SQL Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน SQL Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน
บทเรียน “MVCC และสาเหตุของข้อมูลบวม” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน SQL Academy นี้ได้ไหม
ได้ บทเรียน SQL Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- MVCC และสาเหตุของข้อมูลบวม
- VACUUM, autovacuum, vacuum_cost_delay
- ANALYZE และ pg_statistic
- การสแกนเฉพาะดัชนีและแผนที่การมองเห็น