Index ใน SQL คืออะไร? ควรและไม่ควรใช้เมื่อใด?

Question

Accepted Answer

**Index** คือโครงสร้างข้อมูล (โดยทั่วไปเป็น **B-tree**) ที่ช่วยให้ฐานข้อมูลค้นหาแถวได้อย่างรวดเร็ว**โดยไม่ต้องสแกนทั้งตาราง** — เหมือนดัชนีท้ายเล่มของหนังสือ มันเร่งความเร็วการค้นหา การกรอง การ join และการเรียงลำดับบนคอลัมน์ที่ทำ index ได้อย่างมาก แลกกับพื้นที่จัดเก็บที่เพิ่มขึ้นและการเขียนที่ช้าลง

## index ช่วยได้อย่างไร

```sql
-- without an index on email, this scans EVERY row (slow on a big table) — O(n)
SELECT * FROM users WHERE email = 'ann@x.com';

-- create an index → the database can find the row directly — O(log n)
CREATE INDEX idx_users_email ON users(email);
-- now the same query uses the index → dramatically faster
```

หากไม่มี index ฐานข้อมูลจะทำ **full table scan** (ตรวจสอบทุกแถว) แต่เมื่อมี index มันจะเดินผ่าน B-tree เพื่อค้นหาแถวที่ตรงกันในเวลาเชิงลอการิทึม — เป็นความแตกต่างระหว่างการสแกนหลายล้านแถวกับการค้นหาเพียงไม่กี่ครั้ง

## เมื่อใดควรใช้ index

```text
✓ Columns in WHERE clauses (frequently filtered)
✓ Columns used in JOINs (foreign keys especially)
✓ Columns in ORDER BY (sorting can use the index)
✓ Columns with high SELECTIVITY (many distinct values — email, id)
✓ Primary keys (auto-indexed) and unique constraints
```

## เมื่อใดไม่ควรใช้ index (ข้อแลกเปลี่ยน)

```text
✗ Columns rarely queried — wasted storage and write overhead
✗ Small tables — a full scan is already fast; an index adds no benefit
✗ Low-selectivity columns (e.g. a boolean with 2 values) — index barely helps
✗ Write-heavy columns — EVERY INSERT/UPDATE/DELETE must also update the indexes
  → too many indexes SLOW DOWN writes significantly
```

Index ไม่ได้มาฟรี ๆ: มัน**กินพื้นที่จัดเก็บ**และ**ทำให้การเขียนช้าลง** (ทุกการแก้ไขต้องอัปเดต index ด้วย) การทำ index มากเกินไปจะส่งผลเสียต่อประสิทธิภาพการเขียน

## Composite index และ index ประเภทอื่น ๆ

```sql
CREATE INDEX idx_users_country_name ON users(country, name);   -- COMPOSITE (multi-column)
-- helps WHERE country = ? AND name = ?, and WHERE country = ? (leftmost prefix)
-- but NOT WHERE name = ? alone (order matters!)

CREATE UNIQUE INDEX ...      -- enforces uniqueness
-- also: partial indexes, covering indexes, GIN/GiST (Postgres) for special data
```

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

Index เป็นหนึ่งในหัวข้อที่สำคัญที่สุดในด้านประสิทธิภาพของฐานข้อมูล — มันเป็นเครื่องมือหลักในการทำให้ query รวดเร็ว และการเข้าใจว่าจะใช้เมื่อใดและอย่างไรเป็นความรู้ที่จำเป็นสำหรับทุกคนที่ทำงานกับฐานข้อมูลในระดับใหญ่

คุณค่าหลักนั้นชัดเจน: หากไม่มี index query ที่กรอง join หรือเรียงลำดับบนคอลัมน์จะต้องทำ **full table scan** (ตรวจสอบทุกแถว — ช้าอย่างรุนแรงเมื่อข้อมูลโตขึ้น) ในขณะที่ index เปลี่ยนสิ่งเหล่านี้ให้กลายเป็นการค้นหาเชิงลอการิทึมที่รวดเร็ว — บ่อยครั้งเป็นความแตกต่างระหว่าง query ที่ใช้เวลาเป็นมิลลิวินาทีกับเป็นวินาทีหรือนาที

การเข้าใจ **เมื่อใดควรทำ index** (คอลัมน์ใน WHERE ที่ถูกกรองบ่อย, คอลัมน์ JOIN/foreign-key, คอลัมน์ ORDER BY, คอลัมน์ที่มี selectivity สูง) เป็นพื้นฐานสำคัญต่อประสิทธิภาพของ query

ที่สำคัญไม่แพ้กันคือการเข้าใจ **ข้อแลกเปลี่ยนและเมื่อใดไม่ควรทำ index**: index กินพื้นที่จัดเก็บ และที่สำคัญคือ**ทำให้การเขียนช้าลง** (ทุก INSERT/UPDATE/DELETE ต้องอัปเดต index ทั้งหมด) ดังนั้นการทำ index มากเกินไปจึงส่งผลเสียต่อประสิทธิภาพการเขียน และ index แทบไม่มีประโยชน์บนตารางขนาดเล็กหรือคอลัมน์ที่มี selectivity ต่ำ

ความสมดุลนี้ — การทำ index ในสิ่งที่ถูก query ในขณะที่ไม่ทำ index มากเกินไป — เป็นทักษะสำคัญ

การรู้จัก **composite index** (หลายคอลัมน์ ซึ่งลำดับของคอลัมน์มีผลต่อว่า query ใดที่มันจะช่วยได้) ช่วยเติมเต็มความรู้ด้าน index ในเชิงปฏิบัติ

เนื่องจากประสิทธิภาพของ query เป็นเรื่องวิกฤตสำหรับแอปพลิเคชันจริง และเนื่องจากการทำ index ที่เหมาะสม (index ที่ถูกต้องบนคอลัมน์ที่ถูกต้อง โดยสมดุลความเร็วในการอ่านกับต้นทุนการเขียนและพื้นที่จัดเก็บ) เป็นการปรับแต่งฐานข้อมูลที่ส่งผลมากที่สุด การเชี่ยวชาญ index — วิธีการทำงาน เมื่อใดควรใช้ ข้อแลกเปลี่ยนด้านการเขียน/พื้นที่ และ composite index — จึงเป็นความรู้หลักที่มีคุณค่าสูงสำหรับฐานข้อมูลที่มีประสิทธิภาพ และเป็นหนึ่งในหัวข้อฐานข้อมูลที่สำคัญและถูกถามบ่อยที่สุด