คุณใช้ EXPLAIN และ EXPLAIN ANALYZE อย่างไร?

Question

IT Interview Practice · Accepted Answer

**`EXPLAIN`** แสดง **query execution plan** ของ PostgreSQL — วิธีที่มันจะรัน query (scans, joins, indexes อะไรบ้าง) **`EXPLAIN ANALYZE`** รัน query จริงและแสดงเวลาและจำนวนแถวจริง สิ่งเหล่านี้เป็นเครื่องมือหลักสำหรับการวินิจฉัย query ที่ช้า

## EXPLAIN — แผน (โดยไม่รัน)

```sql
EXPLAIN SELECT * FROM orders WHERE customer_id = 5;
-- shows the PLAN: scan type, estimated cost, estimated rows — but doesn't run it
```

## EXPLAIN ANALYZE — แผนพร้อมข้อมูลการรันจริง

```sql
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- ACTUALLY runs it → shows REAL time, ACTUAL rows, and where time was spent
EXPLAIN (ANALYZE, BUFFERS) SELECT ...;   -- also shows buffer/cache usage
```

`EXPLAIN ANALYZE` มีประโยชน์มากกว่าเพราะมันแสดง performance *จริง* (เวลาจริง, จำนวนแถวจริง) เผยให้เห็นว่า query ใช้เวลาที่ไหนจริง ๆ ไม่ใช่แค่การประมาณการ

## การอ่านแผน: สิ่งสำคัญที่ต้องมองหา

```text
SCAN TYPES (most important):
  Seq Scan      → FULL TABLE SCAN (reads every row) — slow on big tables, often the problem
  Index Scan    → uses an index to find rows — fast
  Index Only Scan → reads only the index (doesn't touch the table) — fastest
  Bitmap Scan   → for combining indexes / many matches

WATCH FOR:
  ✗ Seq Scan on a large table being filtered → likely a MISSING INDEX
  ✗ Estimated rows VERY different from actual rows → outdated statistics (run ANALYZE)
  ✗ Expensive joins, sorts spilling to disk ("external merge")
  ✗ The node with the highest actual time = the bottleneck
```

## ตัวอย่างการวินิจฉัย

```sql
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- "Seq Scan on orders ... actual time=120ms" → a full scan, slow

CREATE INDEX idx_orders_customer ON orders(customer_id);

EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- "Index Scan using idx_orders_customer ... actual time=0.05ms" → fixed!
```

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

`EXPLAIN` และ `EXPLAIN ANALYZE` เป็นเครื่องมือหลักที่จำเป็นสำหรับ **การวินิจฉัยและปรับ query ที่ช้า** ใน PostgreSQL performance ของ query มีความสำคัญยิ่งสำหรับแอปพลิเคชัน และเครื่องมือเหล่านี้คือวิธีที่คุณเข้าใจ *ว่าทำไม* query ถึงช้าและตรวจสอบการแก้ไข ดังนั้นการเชี่ยวชาญมันจึงเป็นความรู้ระดับ senior ที่สำคัญสำหรับงาน performance ของฐานข้อมูล

คุณค่าพื้นฐานคือ **การมองเห็น execution plan**: แทนที่จะเดาว่าทำไม query ถึงช้า `EXPLAIN ANALYZE` (ซึ่งรัน query และแสดงเวลาและจำนวนแถวจริง) เผยให้เห็นว่า Postgres รันมันอย่างไรและใช้เวลาที่ไหน อย่างแม่นยำ

สิ่งสำคัญที่สุดที่ต้องจำได้คือ **scan types** โดยเฉพาะการระบุ **`Seq Scan` (full table scan)** บนตารางขนาดใหญ่ที่ถูก filter ซึ่งมักบ่งชี้ว่า **ขาด index** (ปัญหา performance ของ query ที่พบบ่อยและส่งผลกระทบมากที่สุด) เทียบกับ **`Index Scan`** ที่เร็ว

การเข้าใจวิธีอ่านแผน (scan types, การเปรียบเทียบแถวที่ประมาณการกับแถวจริงเพื่อตรวจหา statistics ที่ล้าสมัย, การระบุ node ที่แพงที่สุดว่าเป็น bottleneck, การเฝ้าระวัง sort ที่ spill ลง disk) เป็นทักษะสำคัญสำหรับการปรับ query

ขั้นตอนการวินิจฉัย — รัน `EXPLAIN ANALYZE`, ระบุ bottleneck (มักเป็น Seq Scan), ทำการแก้ไข (มักเป็นการเพิ่ม index) และรันใหม่เพื่อตรวจสอบ — เป็นแนวทางมาตรฐานที่ขับเคลื่อนด้วยการวัดผลสำหรับการปรับ query

เนื่องจาก query ที่ช้าเป็นสาเหตุสำคัญของ performance ฐานข้อมูลที่แย่ และเนื่องจาก `EXPLAIN`/`EXPLAIN ANALYZE` เป็น *เครื่องมือ* สำหรับวินิจฉัยมัน (เผย index ที่ขาด, แผนที่แย่ และ bottlenecks) และตรวจสอบการปรับ การเชี่ยวชาญมันจึงเป็นความรู้ที่มีคุณค่าสูงสำหรับ performance ของ PostgreSQL มันคือวิธีที่คุณค้นหาและแก้ query ที่ช้าอย่างเป็นระบบแทนการเดา เป็นทักษะสำคัญสำหรับฐานข้อมูลที่มี performance และเป็นหัวข้อที่พบบ่อยสำหรับงานปรับฐานข้อมูล

EXPLAIN — แผน (โดยไม่รัน)

EXPLAIN ANALYZE — แผนพร้อมข้อมูลการรันจริง

การอ่านแผน: สิ่งสำคัญที่ต้องมองหา

ตัวอย่างการวินิจฉัย

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

คำถามที่เกี่ยวข้อง