EXPLAIN แสดงแผน (plan) ที่ optimizer เลือก — ว่ามันจะเข้าถึงแต่ละตารางอย่างไร — โดยไม่รัน query จริง คุณอ่านมันเพื่อยืนยันว่ามีการใช้ index และมีการตรวจแถวจำนวนน้อย
EXPLAIN แสดงแผน (plan) ที่ optimizer เลือก — ว่ามันจะเข้าถึงแต่ละตารางอย่างไร — โดยไม่รัน query จริง คุณอ่านมันเพื่อยืนยันว่ามีการใช้ index และมีการตรวจแถวจำนวนน้อย
const / eq_ref / ref (index lookup, ดี) → range → index (สแกนทั้ง index) → ALL (full table scan, สัญญาณอันตราย)NULL = ไม่มี)Using index (covering, ยอดเยี่ยม), Using filesort / Using temporary (การเรียง/จัดกลุ่มในหน่วยความจำหรือบนดิสก์ — มักปรับให้ดีขึ้นได้)EXPLAIN SELECT * FROM orders WHERE customer_id = 42 ORDER BY created_at;
-- +------+------+------+---------+--------+----------------+
-- | type | key | rows | Extra |
-- | ALL | NULL | 900k | Using where; Using filesort | <- scans everything, sorts
-- +------+------+------+---------+--------+----------------+
-- Add an index that covers the filter AND the sort order:
CREATE INDEX idx_cust_created ON orders (customer_id, created_at);
EXPLAIN SELECT * FROM orders WHERE customer_id = 42 ORDER BY created_at;
-- | type | key | rows | Extra |
-- | ref | idx_cust_created | 30 | Using where | <- seeks 30 rows, no filesort
Index เปลี่ยนการสแกนแบบ ALL บน 900k แถวให้กลายเป็นการ seek แบบ ref เพียง 30 แถว และเพราะ created_at เป็นคอลัมน์ที่สอง แถวจึงออกมาเรียงลำดับไว้เรียบร้อยแล้ว — filesort จึงหายไป
ใช้ EXPLAIN ANALYZE (MySQL 8) เพื่อดู เวลาและจำนวนแถวจริง ด้วย ซึ่งช่วยจับกรณีที่ค่าประมาณผิดพลาด
EXPLAIN คือวิธีที่คุณแทนที่การเดาด้วยหลักฐาน การมองเห็น type: ALL, rows ที่มหาศาล หรือ Using filesort จะบอกคุณได้ทันทีว่า index ตัวไหนขาดหายไป — เป็นเส้นทางที่เร็วที่สุดจาก "หน้านี้ช้า" ไปสู่การแก้ที่ตรงจุด
คลังคำถามสัมภาษณ์งาน IT พร้อมคำตอบโดยละเอียด — ตั้งแต่ระดับ Junior ถึง Senior
บริจาค