เริ่มต้นด้วยแผนการค้นหา จากนั้นแก้ไขต้นทุนที่สูงสุด ใช้ EXPLAIN/ เพื่อดูว่าฐานข้อมูลกำลังทำอะไร เพิ่ม ที่ถูกต้อง ลบปัญหา และเลือกเฉพาะข้อมูลที่คุณต้องการ
เริ่มต้นด้วยแผนการค้นหา จากนั้นแก้ไขต้นทุนที่สูงสุด ใช้ EXPLAIN/ เพื่อดูว่าฐานข้อมูลกำลังทำอะไร เพิ่ม ที่ถูกต้อง ลบปัญหา และเลือกเฉพาะข้อมูลที่คุณต้องการ
EXPLAIN ANALYZEEXPLAIN ANALYZE แสดงแผนการทำงานและเวลาจริง Seq Scan บนตารางขนาดใหญ่เป็นธง
สีแดงดั้งเดิม:
EXPLAIN ANALYZE
SELECT * FROM orders WHERE customer_id = 42;
-- Seq Scan on orders (cost=0.00..18500 rows=120)
-- Filter: (customer_id = 42)
-- rows removed by filter: 999880 ← scanned the whole table!
index แปลงการสแกนแบบเต็มให้เป็นการค้นหาที่รวดเร็ว:
CREATE INDEX idx_orders_customer ON orders (customer_id);
-- Now: Index Scan using idx_orders_customer (cost=0.42..8.5 rows=120)
-- 1,000,000-row scan → ~120-row lookup
indexes มี ต้นทุนสำหรับการเขียน: ทุก INSERT/UPDATE จะต้องอัปเดต index ด้วย ดังนั้นให้สร้าง index สำหรับคอลัมน์ที่คุณกรอง/เข้าร่วม/เรียงลำดับ ไม่ใช่ทุกคอลัมน์ composite index (customer_id, created_at) ใช้สำหรับ WHERE customer_id = ? ORDER BY created_at ในโครงสร้างเดียว
ปัญหา N+1 — คำค้นหาหนึ่งสำหรับรายการ จากนั้นคำค้นหาหนึ่งต่อแถว — เป็นสาเหตุหลักของการช้า แทนที่ด้วย eager loading, JOIN หรือ IN (...) แบบกลุ่ม:
-- N+1: 1 + 100 queries
SELECT * FROM orders; -- then per order: SELECT * FROM users WHERE id = ?
-- Fixed: one JOIN, only needed columns
SELECT o.id, o.total, u.name
FROM orders o JOIN users u ON u.id = o.user_id;
นอกจากนี้ เลือกเฉพาะคอลัมน์ที่จำเป็น (หลีกเลี่ยง SELECT *) และ จัดหน้า ด้วย LIMIT/keyset pagination เพื่อไม่ให้โหลดแถวล้านลาน
ฐานข้อมูลเป็นคอขวดที่พบได้บ่อยที่สุด การอ่านแผนบอกคุณ ว่าทำไม คำค้นหาจึงช้าแทนที่จะเดา index ที่ถูกต้อง การลบ N+1 และการตัด result set จะเปลี่ยนคำค้นหาที่ใช้เวลาหลายวินาทีเป็นมิลลิวินาที อย่างสม่ำเสมอ — โดยไม่ต้องปรับขนาดฮาร์ดแวร์
คลังคำถามสัมภาษณ์งาน IT พร้อมคำตอบโดยละเอียด — ตั้งแต่ระดับ Junior ถึง Senior
บริจาค