SQL ช้า เริ่มตรวจตรงไหน? 5 คำถามก่อนเพิ่ม Index

“รายงานช้า ช่วยเพิ่ม Index ให้หน่อย” ถ้าได้รับคำขอแบบนี้ คุณจะเริ่มจากตรงไหนครับ เปิดดูตารางก่อน หรือถามว่าผู้ใช้รออยู่ตรงขั้นตอนไหน?

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

สมมติว่าหน้ารายงานต้องแสดงคำสั่งซื้อของลูกค้า 120 เฉพาะวันที่ 15 มกราคม 2026 และตาราง orders มีข้อมูลตัวอย่างสองแถวนี้

order_id	amount	customer_id	ordered_at
101	1200	120	2026-01-15 00:00:00
102	800	120	2026-01-16 00:00:00

ก่อนดูผล ลองทายครับว่ารายงานควรแสดงรายการไหน เมื่อใช้คำสั่งนี้กับตารางที่มีข้อมูลตามตัวอย่าง

SELECT order_id, amount
FROM orders
WHERE customer_id = 120
  AND ordered_at >= DATE '2026-01-15'
  AND ordered_at < DATE '2026-01-16';

ผลลัพธ์ที่ควรได้จากข้อมูลตัวอย่าง

ORDER_ID  AMOUNT
--------  ------
     101    1200

รายการ 101 อยู่ในวันที่ต้องการ ส่วนรายการ 102 เป็นเวลาเริ่มต้นของวันที่ 16 จึงไม่ผ่านเงื่อนไข < DATE '2026-01-16' ตัวอย่างนี้ช่วยให้เราเห็นตรงกันว่ารายงานต้องการข้อมูลอะไร ยังไม่ได้บอกว่าคำสั่งนี้เร็วหรือช้าครับ

ทีนี้ ถ้าผู้ใช้บอกว่ารายงานหน้าดังกล่าวช้า เรามีห้าเรื่องที่ควรถามให้ครบ

1. ช้าตรงไหน และจับเวลาจากจุดไหนถึงจุดไหน?

ผู้ใช้อาจเริ่มนับตั้งแต่กดปุ่มค้นหา แล้วหยุดเมื่อข้อมูลแสดงครบหน้าจอ ส่วนคนตรวจ SQL อาจหยุดจับเวลาทันทีที่เห็นแถวแรก ตัวเลขสองชุดนี้วัดคนละช่วงกัน

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

2. SQL ตัวไหนทำให้รายงานนี้รอ?

หน้ารายงานหนึ่งหน้าอาจเรียก SQL หลายคำสั่ง คำว่า “รายงานช้า” จึงยังระบุไม่ได้ว่าต้องตรวจคำสั่งไหน เก็บคำสั่งที่โปรแกรมใช้ในช่วงที่มีปัญหามาดูก่อน

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

3. ตอนที่ช้า ผู้ใช้เลือกเงื่อนไขอะไร?

ในตัวอย่าง เราระบุลูกค้า 120 และช่วงเวลาตั้งแต่เริ่มวันที่ 15 จนถึงก่อนเริ่มวันที่ 16 มกราคม 2026 ไว้ชัดเจน คนที่รับเรื่องต่อจึงรู้ว่าต้องลองด้วยค่าอะไร

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

4. ก่อนเริ่มช้า มีอะไรเปลี่ยนไปบ้าง?

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

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

5. แก้แล้วจะตรวจอย่างไรว่าเร็วขึ้นและผลยังถูก?

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

สำหรับตัวอย่างนี้ ผลที่ต้องได้คือรายการ 101 จำนวนเงิน 1200 ถ้าคำสั่งใหม่ทำงานเร็วขึ้น แต่ดึงรายการ 102 เข้ามาด้วย ก็ยังไม่ผ่านโจทย์ครับ ตรวจทั้งรายการและค่าที่คืนมา โดยใช้จำนวนแถวกับยอดรวมช่วยตรวจเบื้องต้น เพราะสองอย่างนี้อาจเท่ากันได้แม้รายละเอียดบางรายการต่างกัน

เมื่อเก็บห้าเรื่องนี้ครบ เราค่อยดู Execution Plan ซึ่งเป็นแผนลำดับขั้นตอนที่ Oracle ใช้ทำงานกับ SQL แล้วพิจารณาว่าควรปรับคำสั่งหรือ Index ตรงไหนต่อ

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

อ่านหัวข้ออื่นต่อได้ที่ บทความ Oracle บน teeDBA.com