| name | sql-surgeon |
| description | ผ่า query ช้า — รัน EXPLAIN / EXPLAIN ANALYZE ของจริง อ่าน plan ชี้คอขวด rewrite ให้เป็นขั้นๆ จากถูกไปแพง (SARGable rewrite → index → stats → partition) พร้อมพิสูจน์ตัวเลขก่อน-หลังเมื่อรันได้ Trigger on "query นี้ช้า", "sql ช้า", "จูน query", "explain plan", "optimize query", or when the user pastes a slow query. |
sql-surgeon — วินิจฉัยจาก plan จริง ไม่ใช่จากหน้าตา query
Phase 0 — ขอหลักฐานก่อนผ่า
ต้องมีให้ครบก่อนวินิจฉัย (ถามรวบครั้งเดียว / หาเองถ้าเข้าถึงได้):
- Query จริง + engine อะไร (Postgres / MySQL / BigQuery / DuckDB / Spark SQL — ยาแต่ละตัวคนละสูตร)
- EXPLAIN ANALYZE — ถ้ามี DB ต่ออยู่ในเครื่อง/โปรเจกต์ รันเอง อย่ารอ user; ถ้ารันไม่ได้ ขอ plan มา
- ขนาดตารางคร่าวๆ + index ที่มีอยู่ (
\d table / SHOW INDEX / information_schema)
ถ้าไม่มี plan จริงๆ วินิจฉัยได้แต่ต้องประกาศชัด: "นี่คือสมมติฐานจากโครง query ยังไม่ยืนยันจาก plan"
Phase 1 — อ่าน plan หาคอขวด
ไล่หาตามลำดับความบ่อย:
- Seq/full scan บนตารางใหญ่ ที่มี filter — ทำไม index ไม่ถูกใช้? (ไม่มี index / predicate ไม่ SARGable / stats เก่า)
- rows estimated vs actual เพี้ยนแรง (10 เท่าขึ้นไป) — stats เก่า → planner เลือก join ผิด; แก้ที่ ANALYZE ก่อน ไม่ใช่ที่ query
- Join ผิดลำดับ/ผิดชนิด — nested loop บนล้านแถว, hash join ที่ spill
- Sort/Hash spill to disk — work_mem ไม่พอ หรือ sort ที่ตัดได้
- ทำงานซ้ำ — correlated subquery ที่รันต่อแถว, CTE ที่ถูก scan หลายรอบ
Phase 2 — แก้จากถูกไปแพง (หยุดที่ขั้นแรกที่พอ)
| ขั้น | การแก้ | ราคาที่ต้องจ่าย |
|---|
| 1 | Rewrite — ทำ predicate ให้ SARGable (ห้ามห่อคอลัมน์ด้วย function ใน WHERE — ย้ายไปฝั่งค่าคงที่), EXISTS แทน IN (subquery ใหญ่), ตัด SELECT *, filter ก่อน join | ฟรี |
| 2 | Index — ระบุลำดับคอลัมน์ให้ตรง query (equality ก่อน range), พิจารณา covering index | write ช้าลง + พื้นที่ — บอก user เสมอ |
| 3 | Stats / maintenance — ANALYZE, VACUUM, rebuild bloated index | งาน ops |
| 4 | Partition / cluster — ตาราง append-heavy ที่ query ตามช่วงเวลา | โครงสร้างเปลี่ยน |
| 5 | Materialize / denormalize — ทางเลือกสุดท้าย | ความสด + ความซับซ้อน |
Engine ต่างนิสัย — ระบุก่อนแนะนำ: BigQuery ไม่มี index (ใช้ partition + cluster + ลด bytes scanned = ลดเงินตรงๆ), MySQL ไม่มี partial index, Spark ดูที่ shuffle/skew ก่อน
Phase 3 — พิสูจน์
- รันเทียบก่อน–หลังเมื่อทำได้ แสดงตัวเลขจริง (ms, rows scanned, bytes) — ไม่ใช่ "น่าจะเร็วขึ้น"
- ยืนยันผลลัพธ์เหมือนเดิม — query ที่เร็วขึ้นแต่ตอบผิดคือความล้มเหลว (เช็ค row count / checksum เทียบ)
- ถ้าแก้หลายอย่าง ระบุว่าตัวไหนให้ผลเท่าไหร่ — อย่างน้อยแยก rewrite กับ index
กติกา
- ห้ามแนะนำ index แบบหว่าน — ทุก index ต้องชี้ query ที่มันช่วยได้
- syntax/behavior เฉพาะ engine ที่ไม่แน่ใจ ให้เช็คเอกสารจริงก่อนตอบ
