Index​ ​ใน​ ​Database​ ​คือ​อะไร​ ​และ​เหตุ​ใด​ ​Query​ ​บาง​รายการ​จึง​ช้า

Index ใน Database เป็นโครงสร้างช่วยหาแถวที่ตรงเงื่อนไขโดยไม่ต้องไล่อ่านข้อมูลทั้งหมดทุกครั้ง เปรียบได้กับดัชนีหนังสือ แต่ไม่ใช่สวิตช์เพิ่มความเร็วทุก Query การสร้าง Index ต้องอิงรูปแบบค้นหา การเรียง และปริมาณข้อมูลจริง

เมื่อไร Index อาจช่วย

หากหน้ารายการค้นคำขอด้วย customer_id และเรียงตาม created_at บ่อย การมี Index ที่สอดคล้องกับเงื่อนไขอาจช่วยได้ แต่ถ้า Query ดึงข้อมูลเกือบทั้งตาราง หรือใช้เงื่อนไขที่ไม่ตรงกับ Index ระบบอาจเลือกอ่านตารางโดยตรง ดัชนีหลายคอลัมน์ยังขึ้นกับลำดับคอลัมน์และลักษณะ Query จึงไม่ควรเดาจากชื่อ Field อย่างเดียว

ภาพที่ 1: Index ช่วยบางรูปแบบการค้น แต่ต้องตรวจว่าฐานข้อมูลเลือกใช้จริง

ข้อแลกเปลี่ยนของการเพิ่ม Index

Index ใช้พื้นที่และต้องอัปเดตเมื่อเพิ่ม แก้ หรือลบแถว การใส่ Index ทุกคอลัมน์อาจทำให้งานเขียนช้าลงโดยไม่มีประโยชน์ต่อ Query หลัก ปัญหา Query ช้ายังอาจเกิดจากการดึงข้อมูลมากเกิน การ Join ที่ไม่เหมาะ สถิติไม่ตรง หรือรอ Lock จึงต้องวัดก่อนแก้

วิธีตรวจแบบเป็นขั้น

บันทึก Query ที่ช้า ปริมาณข้อมูล และเวลาที่วัด ใช้ EXPLAIN หรือเครื่องมือแผน Query ของฐานข้อมูล ตรวจว่าระบบอ่านแถวเท่าใดและใช้ Index ใด แล้วจึงทดลอง Index หรือปรับ Query ในสภาพใกล้จริง เปรียบเทียบก่อนและหลังทั้งเวลาอ่านและต้นทุนเขียน ไม่ย้ายผลจากข้อมูลสิบแถวไปอ้างกับข้อมูลล้านแถวโดยไม่ทดสอบ

สำหรับรายงาน

แสดง Query ปัญหา แผนก่อนแก้ สมมติฐาน วิธีปรับ และผลหลังแก้พร้อมสภาพแวดล้อม หากยังไม่ได้รันทดสอบ ให้เรียกว่าแนวทางวิเคราะห์ ไม่ใส่ตัวเลขประสิทธิภาพสมมติ

อ่าน Database คืออะไร หรือดู บริการระบบหลังบ้าน

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

ลองกำหนดกรณีศึกษาเป็น หน้า Order ค้นหาตาม customer_id และวันที่แล้วช้า และเขียนขอบเขตให้ชัดว่ามีผู้ใช้กลุ่มใด ข้อมูลใดเข้าสู่ระบบ และต้องการผลลัพธ์อะไร เริ่มจากสภาพก่อนพัฒนา แล้วอธิบายการตัดสินใจที่บทความนี้เกี่ยวข้องโดยใช้ตัวอย่างข้อมูลหรือเหตุการณ์ที่สมมติขึ้นอย่างระบุว่าเป็นตัวอย่าง การกำหนดขอบเขตเช่นนี้ช่วยให้ผู้อ่านแยกหลักการทั่วไปออกจากข้อเท็จจริงของโครงการได้

หลักฐานที่ควรแสดงคือ Query จริง, EXPLAIN ก่อนหลัง, จำนวนแถว และเวลาอ่านเขียน ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

เกณฑ์ประเมินตัวอย่างคือ Index ลดต้นทุน Query เป้าหมายโดยไม่กระทบ write เกินรับได้ ส่วนข้อจำกัดที่ต้องระบุคือ Index ทุกคอลัมน์เพิ่มพื้นที่และงานอัปเดต ไม่ใช่คำตอบอัตโนมัติ หากยังไม่ได้ทดลองกับผู้ใช้หรือข้อมูลจริง ให้เขียนว่าเป็นข้อเสนอเชิงออกแบบ ไม่สรุปเป็นผลที่พิสูจน์แล้ว การมีทั้งเกณฑ์และข้อจำกัดช่วยให้รายงานตรวจสอบเหตุผลได้ และเปิดทางให้ผู้อื่นนำกรณีเดียวกันไปทดสอบซ้ำในบริบทของตน

แหล่งข้อมูลประกอบ

• PostgreSQL: Examining index usage — การใช้ EXPLAIN ตรวจดัชนี
• MySQL: Optimization and Indexes — ประโยชน์และต้นทุนของ Index