Transaction isolation levels คืออะไร?

Question

Accepted Answer

**Isolation levels** ควบคุมว่า transaction ที่ทำงานพร้อมกันสามารถเห็นการเปลี่ยนแปลงที่ยังไม่ได้ commit (หรือกำลังดำเนินการอยู่) ของกันและกันได้มากเพียงใด — โดยแลกเปลี่ยน **ความสอดคล้อง (consistency)** กับ **ประสิทธิภาพ/concurrency** isolation ที่สูงขึ้นป้องกัน anomalies ได้มากขึ้นแต่เพิ่มการ locking/contention

## Concurrency anomalies (สิ่งที่ isolation ป้องกัน)

```text
DIRTY READ        → reading another transaction's UNCOMMITTED changes (which may roll back)
NON-REPEATABLE READ → re-reading a row gives different values (another txn UPDATED it)
PHANTOM READ      → re-running a query returns different ROWS (another txn INSERTED/DELETED)
```

นี่คือปัญหาที่อาจเกิดขึ้นเมื่อ transaction ทำงานพร้อมกัน — isolation levels ควบคุมว่าปัญหาใดถูกป้องกัน

## สี่ isolation levels มาตรฐาน

แต่ละระดับที่สูงขึ้นป้องกัน anomalies ได้มากขึ้น **Read Committed** เป็นค่าเริ่มต้นที่พบบ่อย (ป้องกัน dirty reads); **Serializable** เข้มงวดที่สุด (transactions ทำงานเสมือนทำทีละตัว) แต่จำกัด concurrency มากที่สุด

## การตั้งค่า isolation level

```sql
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
  -- ... operations run at the chosen isolation ...
COMMIT;
```

## การแลกเปลี่ยนพื้นฐาน

```text
Higher isolation → MORE correctness (fewer anomalies), but MORE locking/contention
                   → lower concurrency, potential slowdowns, more deadlocks
Lower isolation  → MORE concurrency/performance, but risk of anomalies
→ Choose based on the data's needs: financial/critical data may need Serializable;
  most apps use Read Committed (the default) as a balance.
→ Note: implementations vary (MVCC vs locking); the SQL standard defines the levels
  but databases differ in details (Postgres, MySQL/InnoDB, etc.).
```

## ทำไมจึงสำคัญ

Transaction isolation levels เป็นความรู้ขั้นสูงที่สำคัญสำหรับการเข้าใจ **concurrency ในฐานข้อมูล** — เมื่อ transaction หลายตัวทำงานพร้อมกัน (อย่างที่เกิดขึ้นในแอปพลิเคชันแบบ multi-user จริง) isolation levels กำหนดการแลกเปลี่ยนระหว่างความสอดคล้องของข้อมูลกับประสิทธิภาพ ดังนั้นการเข้าใจมันจึงมีคุณค่าต่อการสร้างแอปพลิเคชันแบบ concurrent ที่ถูกต้องและมีประสิทธิภาพ

แนวคิดหลักคือ **concurrency anomalies** (dirty reads, non-repeatable reads, phantom reads — ปัญหาที่เกิดขึ้นเมื่อ transactions เห็นการเปลี่ยนแปลงที่กำลังดำเนินการของกันและกัน) และวิธีที่ **สี่ isolation levels** (Read Uncommitted, Read Committed, Repeatable Read, Serializable) ป้องกันปัญหาเหล่านี้มากขึ้นเรื่อย ๆ

การเข้าใจสิ่งนี้สำคัญต่อความถูกต้อง: การเลือก isolation level ที่ต่ำเกินไปอาจปล่อยให้เกิด anomalies ที่ทำให้ข้อมูลเสียหายหรือให้ผลลัพธ์ที่ผิด (เช่น การอ่านข้อมูลที่ยังไม่ commit ซึ่งภายหลังถูก roll back หรือการอ่านที่ไม่สอดคล้อง) ในขณะที่การเลือกสูงเกินไปลด concurrency และประสิทธิภาพ

**การแลกเปลี่ยนพื้นฐาน** — isolation ที่สูงขึ้นหมายถึงความถูกต้องมากขึ้นแต่มีการ locking/contention มากขึ้น (concurrency ต่ำลง, อาจช้าลงและเกิด deadlocks), isolation ที่ต่ำลงหมายถึงประสิทธิภาพมากขึ้นแต่เสี่ยงต่อ anomalies — คือข้อมูลเชิงลึกหลัก: คุณเลือกระดับตามข้อกำหนดความสอดคล้องของข้อมูล (ข้อมูลสำคัญ/การเงินอาจต้องใช้ Serializable; แอปพลิเคชันส่วนใหญ่ใช้ Read Committed เป็นจุดสมดุล)

การรู้ว่าการ implement แตกต่างกัน (MVCC กับ locking) ก็เกี่ยวข้องด้วย

เนื่องจาก concurrency เป็นสิ่งที่มีอยู่โดยธรรมชาติในแอปพลิเคชันฐานข้อมูลจริง และเนื่องจาก isolation levels ควบคุมสมดุลที่สำคัญระหว่างความสอดคล้องกับประสิทธิภาพ (ด้วยการเลือกที่ผิดทำให้เกิด data anomalies หรือปัญหาประสิทธิภาพ) การเข้าใจ isolation levels — anomalies, ระดับต่าง ๆ และการแลกเปลี่ยนระหว่างความสอดคล้องกับ concurrency — จึงเป็นความรู้ระดับ senior ที่มีคุณค่าสำหรับการสร้างระบบแบบ concurrent ที่ถูกต้องและมีประสิทธิภาพ และเป็นหัวข้อสัมภาษณ์ขั้นสูงที่พบบ่อยซึ่งแสดงถึงความเข้าใจ concurrency ของฐานข้อมูล