ข้อผิดพลาดการทำ Database Index ที่พบบ่อยและวิธีแก้
เจาะลึกข้อผิดพลาดในการทำ Database Index ที่ทำให้แอปพลิเคชันช้าลงโดยไม่รู้ตัว พร้อมแนวทางแก้ไขจาก Dev.to
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- การใส่ Index ทุกฟิลด์ใน WHERE clause เพิ่มภาระการเขียนข้อมูล
- ลำดับคอลัมน์ใน Composite Index มีผลต่อประสิทธิภาพการค้นหา
- Foreign Key ที่ไม่มี Index รองรับจะทำให้เกิด Full Table Scan
- ปัญหาความเร็วแอปบางครั้งไม่ใช่เรื่องของ Index แต่ต้องใช้ Caching แทน
การทำ Database Index เป็นเรื่องที่นักพัฒนาทุกคนคุ้นเคย แต่มีเพียงส่วนน้อยเท่านั้นที่พิจารณาอย่างรอบคอบ การเพิ่ม Index เข้าไปแล้วปล่อยผ่านเป็นเรื่องง่าย แต่การตรวจสอบว่า Index นั้นช่วยเพิ่มประสิทธิภาพจริงหรือแค่มอบภาระการเขียน (Write Overhead) ในขณะที่คำสั่งค้นหายังคงช้าอยู่ เป็นสิ่งที่ท้าทายกว่ามาก
บทความนี้ได้รวบรวมข้อผิดพลาดเกี่ยวกับการทำ Index ที่มักปรากฏซ้ำๆ ในโค้ดเบสจริง และแนวทางแก้ไขที่ควรปฏิบัติเพื่อกู้คืนประสิทธิภาพของระบบ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ข้อผิดพลาดแรกคือการใส่ Index ทุกคอลัมน์ที่ปรากฏในคำสั่ง WHERE โดยปัญหาคือ Index ทุกตัวมีต้นทุนในการเขียน ทั้งการ INSERT, UPDATE และ DELETE ที่ต้องอัปเดตทุก Index บนตารางนั้น ตารางที่มี Index ถึง 10 ตัวสามารถเปลี่ยนการเพิ่มข้อมูลธรรมดาให้กลายเป็นภาระเบื้องหลังถึง 10 การดำเนินการ
แนวทางที่ดีกว่าคือการสร้าง Index ตามรูปแบบการใช้งานจริง (Query Patterns) ไม่ใช่ตามสมมติฐาน โดยใช้เครื่องมือ Query Planner เช่น EXPLAIN ใน Postgres และ MySQL เพื่อดูว่าระบบกำลังสแกนอะไรอยู่ และสร้าง Index สำหรับรูปแบบการเข้าถึงเหล่านั้นโดยเฉพาะ
การวิเคราะห์เพิ่มเติม: การใช้ Index อย่างพร่ำเพรื่อมักเกิดขึ้นจากความเข้าใจผิดว่ายิ่งมีมากยิ่งดี แต่ในความเป็นจริง Write Amplification ที่เกิดขึ้นจากการอัปเดต Index จำนวนมากอาจส่งผลกระทบต่อ I/O ของดิสก์อย่างรุนแรงเมื่อระบบมีปริมาณทราฟฟิกสูง การจำกัดเฉพาะ Index ที่จำเป็นจริงๆ จึงเป็นหัวใจสำคัญของการปรับแต่งฐานข้อมูลเชิงลึก
ข้อผิดพลาดต่อมาคือการสลับลำดับของ Composite Index โดย Composite Index บน (user_id, created_at) นั้นไม่เหมือนกับ (created_at, user_id) ลำดับมีความสำคัญเพราะ Index ประเภทนี้ใช้งานได้อย่างมีประสิทธิภาพเฉพาะแบบซ้ายไปขวา (Left-to-Right Prefix) เท่านั้น หากคำสั่งค้นหากรองด้วย user_id ก่อนเสมอ ลำดับ (user_id, created_at) จะรองรับได้ทั้งสองกรณี แต่หากกรองด้วย created_at อย่างเดียว Index นี้จะไม่ถูกใช้อย่างมีประสิทธิภาพ
นอกจากนี้ ความสัมพันธ์แบบ Foreign Key ที่ไม่มี Index รองรับก็เป็นอีกจุดบอดสำคัญ ทุกครั้งที่มีการ JOIN, Cascading Delete หรือค้นหาข้อมูลลูกของแม่ จะทำให้เกิดการสแกนตารางแบบเต็มรูปแบบ (Full Table Scan) ซึ่งเป็นสาเหตุที่แท้จริงเบื้องหลังแดชบอร์ดที่ช้าลงเรื่อยๆ ตามขนาดของตารางที่โตขึ้น
สุดท้าย การมี Index ไม่ได้การันตีว่าฐานข้อมูลจะใช้งานมัน ความไม่ตรงกันของประเภทข้อมูล การครอบคอลัมน์ด้วยฟังก์ชันใน WHERE clause หรือการใช้ LIKE ที่มี Wildcard นำหน้า ล้วนทำให้ Index ถูกละเลยโดยไม่มีการแจ้งเตือน การรัน EXPLAIN ANALYZE จึงเป็นหนทางเดียวในการยืนยันว่า Index ที่เพิ่มเข้าไปนั้นทำงานจริง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น