0Pricing
SQL Academy · บทเรียน

การระบุและแก้ไขคำสั่งค้นหาที่ทำงานช้า

ใช้ pg_stat_statements, log_min_duration_statement และ EXPLAIN เพื่อค้นหาคำสั่งค้นหาที่ช้าและแก้ไขอย่างตรงจุด

การระบุและแก้ไขคำสั่งค้นหาที่ทำงานช้า เป็นบทเรียน SQL Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน SQL Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส SQL Academy มีบทเรียนทั้งหมด 4 บทเรียน

ขั้นตอนที่ 1 ค้นหาคำสั่งที่ช้า

อย่าปรับปรุงประสิทธิภาพโดยไม่มีข้อมูล ให้ใช้สิ่งต่อไปนี้:

  • pg_stat_statements — คำสั่งค้นหาที่มีเวลารวมสูงสุด
  • log_min_duration_statement — บันทึกคำสั่งค้นหาที่ใช้เวลาเกินค่ากำหนด
  • pgBadger — รายงานที่อ่านง่ายจากล็อก

การตั้งค่า pg_stat_statements

เปิดใช้ส่วนขยายและกำหนดค่า shared_preload_libraries:

-- postgresql.conf
shared_preload_libraries = 'pg_stat_statements'

-- After restart:
CREATE EXTENSION pg_stat_statements;

คำสั่งค้นหาที่หนักที่สุด 10 อันดับแรก

คำสั่งค้นหาเดียวที่มีประโยชน์ที่สุดสำหรับ DBA ทุกคน:

SELECT query,
       calls,
       total_exec_time,
       mean_exec_time,
       rows
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

บันทึกคำสั่งค้นหาที่ช้า

กำหนดค่าเกณฑ์แล้วอ่านล็อก:

-- postgresql.conf
log_min_duration_statement = '500ms'
-- All queries running > 500ms are logged.

ขั้นตอนที่ 2 จำลองปัญหาด้วย EXPLAIN ANALYZE

สำหรับคำสั่งค้นหาที่ช้าแต่ละรายการ ให้เรียกใช้ EXPLAIN ANALYZE ในสภาพแวดล้อมที่เป็นตัวแทนของการใช้งานจริง (ใช้ข้อมูลที่ใกล้เคียงกับระบบจริง) ตรวจสอบสิ่งต่อไปนี้:

  • โหนดที่มีเวลาใช้งานจริงสูงที่สุด
  • ช่องว่างที่มากที่สุดระหว่างจำนวนแถวที่ประมาณการกับจำนวนแถวจริง
  • มีการใช้ดัชนีที่เหมาะสมหรือไม่

วิธีแก้ไขที่พบบ่อย

  • ไม่มีดัชนีบนคอลัมน์ที่ใช้ใน WHERE / JOIN
  • เงื่อนไขคัดกรองที่ใช้ดัชนีไม่ได้ (มีฟังก์ชันบนคอลัมน์) — เพิ่มดัชนีบน expression หรือเขียนใหม่
  • สถิติล้าสมัย — เรียกใช้ ANALYZE
  • ชนิดข้อมูลไม่ถูกต้อง (ทำให้เกิดการแปลงชนิดโดยนัย) — แก้ชนิดข้อมูลของคอลัมน์
  • เงื่อนไข OR — เขียนใหม่เป็น UNION ของคำสั่งค้นหาที่มีเงื่อนไขเดียว
  • SELECT * ดึงข้อมูลมากเกินไป — ลดจำนวนคอลัมน์ที่เลือก

สถิติล้าสมัย

หากจำนวนแถวที่ประมาณการแตกต่างจากจำนวนแถวจริงอย่างมาก ให้เรียกใช้ ANALYZE ก่อน:

ANALYZE orders;
-- Or rely on autovacuum to do it periodically.

ตรวจสอบความสมเหตุสมผลของดัชนี

แสดงรายการดัชนีบนตารางและขนาดของดัชนี:

SELECT indexrelname, pg_size_pretty(pg_relation_size(indexrelid))
FROM pg_stat_user_indexes
WHERE relname = 'orders'
ORDER BY pg_relation_size(indexrelid) DESC;

ดัชนีที่ไม่ได้ใช้งาน

ค้นหาดัชนีที่ไม่เคยถูกใช้งาน:

SELECT schemaname, relname, indexrelname, idx_scan
FROM pg_stat_user_indexes
WHERE idx_scan = 0
ORDER BY pg_relation_size(indexrelid) DESC;
-- Consider dropping them — they slow writes for no read benefit.

การแย่งใช้ล็อก

บางครั้งคำสั่งค้นหาที่ดูเหมือน "ช้า" เป็นเพราะกำลังรอล็อก ให้ตรวจสอบ pg_stat_activity สำหรับ wait_event:

SELECT pid, state, wait_event_type, wait_event, query
FROM pg_stat_activity
WHERE state <> 'idle';

รูปแบบการเขียนคำสั่งค้นหาใหม่

  • ย้ายตัวกรองไปไว้ใน WHERE
  • แทนที่คำสั่งค้นหาย่อยแบบสัมพันธ์กันใน SELECT ด้วย JOIN + GROUP BY
  • แทนที่ OR ด้วย UNION ALL ของคำสั่งค้นหาที่ใช้ดัชนี
  • ใช้ฟังก์ชันหน้าต่างแทนการเชื่อมตารางกับตัวเอง
  • จัดเก็บคำสั่งค้นหาย่อยที่ใช้ซ้ำไว้ล่วงหน้าด้วย CTE (เมื่อตัววางแผนสับสน)

ทำซ้ำเพื่อปรับปรุง

การปรับแต่งประสิทธิภาพเป็นวงจร: วัดผล → ตั้งสมมติฐาน → เปลี่ยนแปลง → วัดผล อย่าคาดเดา

สรุป

ค้นหาคำสั่งค้นหาที่ช้าด้วย pg_stat_statements วินิจฉัยด้วย EXPLAIN ANALYZE แก้ไขด้วยดัชนี / ANALYZE / การเขียนใหม่ แล้วทำซ้ำเพื่อปรับปรุง

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ส่วนขยาย PostgreSQL ใดแสดงคำสั่งค้นหาที่ใช้เวลามากที่สุดโดยพิจารณาจากเวลาทำงานรวม

คำถามที่พบบ่อย

บทเรียน “การระบุและแก้ไขคำสั่งค้นหาที่ทำงานช้า” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การระบุและแก้ไขคำสั่งค้นหาที่ทำงานช้า” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส SQL Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส SQL Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การระบุและแก้ไขคำสั่งค้นหาที่ทำงานช้า”

ใช้ pg_stat_statements, log_min_duration_statement และ EXPLAIN เพื่อค้นหาคำสั่งค้นหาที่ช้าและแก้ไขอย่างตรงจุด คุณปฏิบัติ SQL Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน SQL Academy หรือไม่

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

บทเรียน “การระบุและแก้ไขคำสั่งค้นหาที่ทำงานช้า” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน SQL Academy นี้ได้ไหม

ได้ บทเรียน SQL Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การอ่าน EXPLAIN และ EXPLAIN ANALYZE
  2. การสแกนตามลำดับเทียบกับการสแกนด้วยดัชนี
  3. การรวมแบบแฮชเทียบกับการรวมแบบผสานเทียบกับลูปซ้อน
  4. การระบุและแก้ไขคำสั่งค้นหาที่ทำงานช้า
← กลับไปที่ SQL Academy