ทำไมฐานข้อมูลดึงข้อมูลเร็วได้แม้มีข้อมูลเป็นล้านแถว? เพราะ Index

เมื่อพูดถึงฐานข้อมูล หลายคนอาจสงสัยว่าทำไมระบบถึงสามารถค้นหาข้อมูลได้เร็วมาก ทั้งที่ในตารางอาจมีข้อมูลอยู่หลักล้านหรือมากกว่านั้น คำตอบสำคัญอยู่ที่สิ่งที่เรียกว่า Index

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

Index คืออะไร

Index คือโครงสร้างข้อมูลที่ช่วยให้ฐานข้อมูลค้นหาข้อมูลได้เร็วขึ้น โดยไม่ต้องไล่อ่านทุกแถวในตารางเสมอไป

เวลาที่เราเขียนคำสั่ง SQL เช่น

SELECT * FROM users WHERE email = 'a@b.com';

ถ้าคอลัมน์ email ไม่มี Index ฐานข้อมูลอาจต้องทำงานแบบ Full Table Scan หรืออ่านทุกแถวในตาราง แล้วค่อยตรวจสอบทีละแถวว่าเป็นข้อมูลที่ตรงเงื่อนไขหรือไม่

แต่ถ้าคอลัมน์ email มี Index ฐานข้อมูลจะสามารถเข้าถึงตำแหน่งข้อมูลที่เกี่ยวข้องได้เร็วกว่าอย่างมาก ทำให้การค้นหาจากข้อมูลจำนวนมหาศาลใช้เวลาลดลงอย่างชัดเจน

ทำไม Index ถึงช่วยให้เร็วขึ้น

Index ที่พบบ่อยในฐานข้อมูลจำนวนมากคือแบบ B-Tree ซึ่งเก็บข้อมูลในลักษณะเรียงลำดับและแตกแขนงเหมือนต้นไม้ ทำให้การค้นหาไม่ต้องไล่จากต้นจนจบแบบเส้นตรง

ในเชิงแนวคิด การค้นหาแบบไม่มี Index มักใกล้เคียงกับความซับซ้อนระดับ O(n) คือยิ่งข้อมูลมาก เวลาค้นหาก็ยิ่งเพิ่มขึ้นตามจำนวนแถว

แต่ถ้ามี Index การค้นหามักลดลงเหลือประมาณ O(log n) ซึ่งต่างกันมากเมื่อข้อมูลมีขนาดใหญ่ เช่น จากหลักหมื่น หลักแสน ไปจนถึงหลักล้านแถว

ยิ่งฐานข้อมูลใหญ่เท่าไร ความได้เปรียบของ Index ก็ยิ่งชัดเจนมากขึ้นเท่านั้น

ตัวอย่างที่เห็นภาพชัด

สมมติว่ามีตาราง users จำนวน 5,000,000 แถว และเราต้องการค้นหาผู้ใช้จากอีเมล

SELECT * FROM users WHERE email = 'a@b.com';

• ถ้า email ไม่มี Index ฐานข้อมูลอาจต้องสแกนตารางยาวมาก
• ถ้า email มี Index ฐานข้อมูลจะสามารถพุ่งไปยังข้อมูลที่ต้องการได้แทบจะทันที

นี่คือเหตุผลที่ในระบบจริง คอลัมน์ที่ใช้ค้นหาบ่อยมักถูกพิจารณาให้สร้าง Index ไว้ก่อน

มือใหม่ควรเริ่มสร้าง Index ที่คอลัมน์ไหน

การสร้าง Index ไม่ควรทำแบบสุ่ม แต่ควรเลือกจากรูปแบบการใช้งานจริงของ query โดยจุดเริ่มต้นที่ดีมีดังนี้

1) คอลัมน์ที่ถูกใช้ใน WHERE บ่อย

ตัวอย่างเช่น

• email
• phone
• status
• created_at

หากระบบมีการค้นหาหรือกรองข้อมูลจากคอลัมน์เหล่านี้บ่อย การมี Index มักช่วยให้ query เร็วขึ้นอย่างชัดเจน

2) คอลัมน์ที่ถูกใช้ใน JOIN บ่อย

ตัวอย่างเช่น

• user_id
• order_id
• product_id

การ JOIN ตารางขนาดใหญ่โดยไม่มี Index บนคีย์ที่ใช้เชื่อมกัน อาจทำให้ประสิทธิภาพลดลงมาก

3) คอลัมน์ที่ใช้ใน ORDER BY หรือ GROUP BY บ่อย

Index อาจช่วยงานจัดเรียงและจัดกลุ่มได้ แต่ต้องพิจารณาร่วมกับรูปแบบ query ด้วย ไม่ใช่ว่าสร้างแล้วจะช่วยในทุกกรณี

ดูแผนการทำงานของ Query ก่อนเดา

หนึ่งในทักษะสำคัญของคนทำงานด้านฐานข้อมูลคือการดูว่า query ถูกประมวลผลอย่างไร แทนที่จะคาดเดาเองว่าเร็วหรือช้า

คำที่ควรจำมีดังนี้

• Using index
• Index Scan
• Seek

คำเหล่านี้มักบอกเป็นนัยว่า query มีแนวโน้มทำงานได้เร็ว

ส่วนคำที่ควรระวังคือ

• Full Scan
• Seq Scan

เมื่อข้อมูลมีขนาดใหญ่ คำเหล่านี้มักหมายถึงการอ่านข้อมูลจำนวนมาก และอาจกลายเป็นคอขวดของระบบได้

Index ไม่ได้ฟรี และมีต้นทุนเสมอ

แม้ Index จะช่วยให้การอ่านข้อมูลเร็วขึ้น แต่ก็ไม่ได้มีแต่ข้อดี การสร้าง Index มีค่าใช้จ่ายที่ควรรู้ก่อนใช้งานจริง

1) ทำให้การเขียนข้อมูลช้าลง

ทุกครั้งที่มีคำสั่ง INSERT, UPDATE หรือ DELETE ฐานข้อมูลไม่ได้แก้แค่ข้อมูลในตาราง แต่ยังต้องอัปเดต Index ที่เกี่ยวข้องด้วย ทำให้การเขียนข้อมูลมีต้นทุนเพิ่มขึ้น

2) ใช้พื้นที่จัดเก็บเพิ่ม

Index ต้องใช้ storage และใช้ cache เพิ่มขึ้น หากมีมากเกินไปอาจทำให้สิ้นเปลืองทรัพยากรโดยไม่จำเป็น

3) สร้างผิดจุดอาจไม่ช่วย

หากสร้าง Index บนคอลัมน์ที่มีค่าซ้ำเยอะมาก เช่น gender ในบางกรณีฐานข้อมูลอาจมองว่าไม่คุ้มที่จะใช้ Index เพราะไม่ช่วยลดช่วงการค้นหาได้มากพอ

Covering Index คืออะไร และทำไมถึงน่าสนใจ

สิ่งที่หลายคนอาจยังไม่รู้คือ บางครั้ง Index สามารถช่วยให้ฐานข้อมูลตอบคำถามได้โดยแทบไม่ต้องกลับไปอ่านข้อมูลจากตารางหลักเลย

แนวคิดนี้เรียกว่า Covering Index

ถ้า query ต้องการเพียงบางคอลัมน์ และคอลัมน์ทั้งหมดนั้นอยู่ใน Index ครบ ฐานข้อมูลอาจตอบผลลัพธ์จาก Index ได้โดยตรง ช่วยลด I/O ได้มาก โดยเฉพาะในงานที่มีการอ่านข้อมูลถี่และซ้ำบ่อย

ก่อนสร้าง Index ต้องดูรูปแบบการค้นหา

แนวคิดสำคัญคือ อย่าคิดแค่ว่า “อยากให้เร็ว” แต่ต้องคิดว่า “ผู้ใช้ค้นหาอย่างไร”

Index จะให้ผลดีเมื่อมันสอดคล้องกับรูปแบบ query ที่เกิดขึ้นจริง เช่น

• ถ้าค้นหาตามช่วงเวลาใน created_at การมี Index ที่คอลัมน์นี้มักช่วยได้มาก
• ถ้าค้นหาด้วย LIKE '%abc%' ซึ่งมี % นำหน้า B-Tree Index มักช่วยได้น้อยหรือแทบไม่ช่วยเลย

ในกรณีแบบหลัง อาจต้องพิจารณาเทคนิคอื่น เช่น full-text search หรือ trigram index แทน

เช็กลิสต์ก่อนกดสร้าง Index

ก่อนสร้าง Index ทุกครั้ง ควรถามตัวเองด้วยคำถามเหล่านี้

• มี query ช้าจริงหรือไม่
• คอลัมน์นี้ถูกใช้ใน WHERE หรือ JOIN บ่อยแค่ไหน
• คอลัมน์นี้มีการเปลี่ยนแปลงบ่อยหรือไม่
• ข้อมูลในคอลัมน์นี้มีค่าซ้ำมากจน Index ไม่คุ้มหรือเปล่า

การตอบคำถามเหล่านี้จะช่วยให้เราออกแบบ Index ได้แม่นยำขึ้น และไม่สร้างภาระให้ระบบโดยไม่จำเป็น

สรุป

Index คือทางลัดในการค้นหาข้อมูลของฐานข้อมูล ช่วยให้ query ที่ต้องค้นหาหรือกรองข้อมูลทำงานเร็วขึ้นมาก โดยเฉพาะเมื่อข้อมูลมีขนาดใหญ่ระดับหลักล้านแถว

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

หากเลือกใช้ได้ถูกจุด Index สามารถยกระดับประสิทธิภาพของระบบได้อย่างเห็นผลแทบจะทันที