MySQL Slow Query Log — วิเคราะห์ Query ช้า

เผยแพร่ 7 เมษายน 2569

เมื่อแอปพลิเคชันเริ่มตอบสนองช้าลง หนึ่งในขั้นตอนแรกที่ DBA และนักพัฒนาควรทำคือตรวจสอบว่ามีคำสั่ง SQL ใดบ้างที่ใช้เวลานานเกินไป MySQL มีฟีเจอร์ในตัวที่ช่วยบันทึกคำสั่งเหล่านี้โดยอัตโนมัติ นั่นคือ Slow Query Log ซึ่งจะจับทุกคำสั่งที่ใช้เวลาเกินค่าที่กำหนดไว้ ช่วยให้ค้นหาจุดคอขวดได้อย่างตรงจุดโดยไม่ต้องเดา

บทความนี้จะอธิบายวิธีเปิดใช้งานและตั้งค่า Slow Query Log อย่างละเอียด ตั้งแต่การกำหนดค่าใน Configuration File, การเปิดใช้งานแบบ Runtime, การอ่านและตีความ Log File, การวิเคราะห์ด้วยเครื่องมืออย่าง mysqldumpslow และ pt-query-digest ไปจนถึงแนวทางปฏิบัติที่ดีในการจัดการ Log บน Production Server

Slow Query Log คืออะไร

Slow Query Log เป็นระบบบันทึกที่ MySQL สร้างขึ้นเพื่อจับคำสั่ง SQL ที่ใช้เวลาดำเนินการนานเกินค่า Threshold ที่กำหนดไว้ในตัวแปร long_query_time เมื่อเปิดใช้งาน ระบบจัดการฐานข้อมูลจะเขียนรายละเอียดของคำสั่งเหล่านี้ลงไฟล์ Log โดยอัตโนมัติ รวมถึงเวลาที่ใช้ จำนวน Row ที่ตรวจสอบ และจำนวน Row ที่ส่งกลับ

ฟีเจอร์นี้ต่างจากการใช้ EXPLAIN ตรงที่ไม่ต้องเลือกคำสั่งมาวิเคราะห์ทีละตัว แต่ระบบจะจับทุกคำสั่งที่ช้าให้อัตโนมัติ เหมาะสำหรับการ Monitor ระบบ Production ที่มีคำสั่งจำนวนมากและไม่สามารถตรวจสอบทีละรายการได้

เปิดใช้งานผ่าน Configuration File

วิธีที่แนะนำสำหรับ Production คือการตั้งค่าใน Configuration File เพื่อให้คงอยู่แม้ Restart Service ให้เปิดไฟล์ my.cnf (หรือ mysqld.cnf บน Ubuntu) แล้วเพิ่มการตั้งค่าใน Section [mysqld]

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 1
min_examined_row_limit = 100

slow_query_log = 1 — เปิดใช้งานระบบบันทึกคำสั่งที่ช้า ค่า 0 คือปิด

slow_query_log_file — กำหนดพาธของไฟล์บันทึก หากไม่ระบุ ระบบจะใช้ชื่อ hostname-slow.log ใน Data Directory

long_query_time = 1 — คำสั่งที่ใช้เวลาเกิน 1 วินาทีจะถูกบันทึก ค่า Default คือ 10 วินาที ซึ่งสูงเกินไปสำหรับเว็บแอปพลิเคชันส่วนใหญ่ แนะนำให้เริ่มที่ 1 วินาทีแล้วค่อยปรับตามความเหมาะสม ค่านี้รองรับทศนิยมได้ เช่น 0.5 สำหรับครึ่งวินาที

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

min_examined_row_limit = 100 — บันทึกเฉพาะคำสั่งที่ตรวจสอบมากกว่า 100 Row ช่วยกรอง Noise จากคำสั่งเล็ก ๆ ที่ไม่ใช้ดัชนีแต่ไม่ส่งผลกระทบ

หลังแก้ไข Configuration ให้ Restart Service เพื่อให้มีผล

sudo systemctl restart mysqld

เปิดใช้งานแบบ Runtime ไม่ต้อง Restart

หากไม่สะดวก Restart Service สามารถเปิดใช้งานแบบ Runtime ได้ทันทีผ่านคำสั่ง SET GLOBAL การตั้งค่าแบบนี้จะมีผลจนกว่าจะ Restart Service

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
SET GLOBAL log_queries_not_using_indexes = 'ON';
SET GLOBAL min_examined_row_limit = 100;

ตรวจสอบว่าการตั้งค่ามีผลแล้ว

SHOW VARIABLES LIKE 'slow_query%';
SHOW VARIABLES LIKE 'long_query_time';
SHOW VARIABLES LIKE 'log_queries_not_using_indexes';

ข้อควรระวังสำหรับ Connection ที่เปิดอยู่ก่อน — ค่า long_query_time ที่เปลี่ยนผ่าน SET GLOBAL จะมีผลเฉพาะ Connection ใหม่เท่านั้น Connection เดิมที่เปิดอยู่แล้วยังคงใช้ค่าเก่า หากต้องการให้มีผลทันทีใน Session ปัจจุบัน ต้องรัน SET SESSION long_query_time = 1 เพิ่ม

ตั้งค่า long_query_time ที่เหมาะสม

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

สำหรับเว็บแอปพลิเคชันทั่วไปที่ผู้ใช้คาดหวังเวลาตอบสนองเร็ว แนะนำให้เริ่มที่ 1 วินาที สำหรับระบบ API ที่ต้องการ Latency ต่ำ อาจตั้งค่าที่ 0.5 วินาทีหรือต่ำกว่า ส่วนระบบ Batch Processing หรือ Reporting ที่คำสั่งยาวเป็นเรื่องปกติ อาจตั้งที่ 5-10 วินาที

กลยุทธ์ที่ดีคือเริ่มจากค่าต่ำ เช่น 0.5 วินาที เพื่อจับภาพรวมทั้งหมดก่อน จากนั้นค่อยปรับขึ้นเมื่อแก้ไขคำสั่งที่ช้าที่สุดแล้ว วิธีนี้ช่วยให้มั่นใจว่าไม่พลาดปัญหาสำคัญในช่วงเริ่มต้น

อ่านและตีความไฟล์บันทึก

ไฟล์ที่บันทึกได้จะมีรูปแบบดังนี้สำหรับแต่ละคำสั่ง

# Time: 2025-01-15T08:23:45.123456Z
# User@Host: appuser[appuser] @ localhost []  Id: 12345
# Query_time: 3.456789  Lock_time: 0.000123  Rows_sent: 150  Rows_examined: 1500000
SET timestamp=1736929425;
SELECT o.order_id, c.name, p.product_name
FROM orders o
JOIN customers c ON o.customer_id = c.id
JOIN products p ON o.product_id = p.id
WHERE o.created_at BETWEEN '2024-01-01' AND '2024-12-31'
ORDER BY o.created_at DESC;

Time — เวลาที่คำสั่งทำงานเสร็จ ไม่ใช่เวลาเริ่มต้น

User@Host — ผู้ใช้และ Host ที่ส่งคำสั่ง ช่วยระบุว่าคำสั่งมาจากแอปพลิเคชันใด

Query_time — เวลาที่ใช้ดำเนินการ (หน่วยวินาที) นี่คือตัวเลขสำคัญที่สุด คำสั่งในตัวอย่างใช้เวลา 3.46 วินาที

Lock_time — เวลาที่รอ Lock ถ้าค่านี้สูง แสดงว่ามีปัญหา Contention ไม่ใช่ปัญหา Query Optimization

Rows_sent — จำนวน Row ที่ส่งกลับให้ Client

Rows_examined — จำนวน Row ที่ระบบต้อง Scan ทั้งหมด ถ้าค่านี้สูงกว่า Rows_sent มาก แสดงว่าคำสั่งนี้ Scan ข้อมูลเกินจำเป็น ในตัวอย่าง Scan 1.5 ล้าน Row แต่ส่งกลับเพียง 150 Row ซึ่งเป็นสัญญาณชัดเจนว่าขาดดัชนีที่เหมาะสม

วิเคราะห์ด้วย mysqldumpslow

เมื่อไฟล์บันทึกมีคำสั่งจำนวนมาก การอ่านทีละรายการไม่เหมาะสม mysqldumpslow เป็นเครื่องมือที่มากับ MySQL ช่วยสรุปและจัดกลุ่มคำสั่งที่คล้ายกัน โดยแทนที่ค่าตัวเลขและ String ด้วย N และ S ตามลำดับ ทำให้เห็นรูปแบบคำสั่งที่เป็นปัญหาได้ชัดเจน

# แสดง 10 คำสั่งที่ช้าที่สุด เรียงตามเวลารวม
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

# แสดง 10 คำสั่งที่ถูกเรียกบ่อยที่สุด
mysqldumpslow -s c -t 10 /var/log/mysql/slow.log

# แสดง 10 คำสั่งที่ Scan Row มากที่สุด
mysqldumpslow -s r -t 10 /var/log/mysql/slow.log

# แสดงเฉพาะคำสั่งที่เกี่ยวกับตาราง orders
mysqldumpslow -s t -t 10 -g "orders" /var/log/mysql/slow.log

ตัวเลือก -s กำหนดวิธีเรียงลำดับ โดย t คือเรียงตามเวลารวม (Total Time), c คือเรียงตามจำนวนครั้ง (Count), r คือเรียงตามจำนวน Row ที่ส่งกลับ, at คือเรียงตามเวลาเฉลี่ย (Average Time) และ ar คือเรียงตามจำนวน Row เฉลี่ย ส่วน -t กำหนดจำนวนผลลัพธ์ที่ต้องการแสดง

ตัวอย่างผลลัพธ์จาก mysqldumpslow

Count: 482  Time=2.35s (1132s)  Lock=0.00s (0s)  Rows=150.2 (72396)
  SELECT o.order_id, c.name FROM orders o JOIN customers c ON o.customer_id = c.id WHERE o.created_at BETWEEN 'S' AND 'S' ORDER BY o.created_at DESC

Count: 156  Time=1.87s (291s)  Lock=0.00s (0s)  Rows=1.0 (156)
  SELECT * FROM products WHERE product_name LIKE 'S'

จากผลลัพธ์ คำสั่งแรกถูกเรียก 482 ครั้ง ใช้เวลาเฉลี่ย 2.35 วินาทีต่อครั้ง รวมเวลาทั้งหมด 1,132 วินาที นี่คือคำสั่งที่ควรปรับปรุงก่อนเพราะส่งผลกระทบมากที่สุด ส่วนคำสั่งที่สองแม้เรียกน้อยกว่าแต่ Pattern การใช้ LIKE อาจเป็นสัญญาณว่าขาด Full-Text Index

วิเคราะห์เชิงลึกด้วย pt-query-digest

pt-query-digest เป็นเครื่องมือจาก Percona Toolkit ที่ให้รายงานละเอียดกว่า mysqldumpslow มาก รวมถึง Response Time Distribution, Histogram และสถิติเชิงลึกของแต่ละกลุ่มคำสั่ง เป็นเครื่องมือมาตรฐานที่ DBA มืออาชีพใช้กันอย่างแพร่หลาย

ติดตั้ง Percona Toolkit

บน Ubuntu/Debian

sudo apt install percona-toolkit -y

บน CentOS/RHEL/AlmaLinux

sudo yum install percona-toolkit -y

รันการวิเคราะห์

# วิเคราะห์ไฟล์ Log ทั้งหมด
pt-query-digest /var/log/mysql/slow.log

# วิเคราะห์เฉพาะช่วงเวลาที่กำหนด
pt-query-digest /var/log/mysql/slow.log --since '2025-01-15 00:00:00' --until '2025-01-15 23:59:59'

# บันทึกผลลัพธ์เป็นไฟล์
pt-query-digest /var/log/mysql/slow.log > /tmp/slow_report.txt

# วิเคราะห์เฉพาะคำสั่งที่เกี่ยวกับ Database เฉพาะ
pt-query-digest /var/log/mysql/slow.log --filter '$event->{db} eq "myapp_db"'

ตีความรายงาน pt-query-digest

รายงานแบ่งเป็น 3 ส่วนหลัก ส่วนแรกคือ Overall Summary ที่แสดงภาพรวมของคำสั่งทั้งหมด

# Overall: 2.50k total, 45 unique, 1.04 QPS, 1.25x concurrency
# Time range: 2025-01-15T00:00:00 to 2025-01-15T23:59:59
# Attribute     total    min     max     avg     95%    stddev   median
# Exec time     3024s   100ms   45s     1s      5s     2s       500ms
# Lock time     12s     0       2s      5ms     1ms    50ms     0
# Rows sent     1.25M   0       50.00k  500     5.00k  2.50k    10
# Rows examine  850.5M  0       15.00M  340.2k  2.00M  1.50M    1.00k

ส่วนนี้บอกว่ามีคำสั่งทั้งหมด 2,500 รายการ จาก 45 รูปแบบที่ไม่ซ้ำกัน ใช้เวลารวม 3,024 วินาที ค่า 95% อยู่ที่ 5 วินาที หมายความว่า 95% ของคำสั่งใช้เวลาไม่เกิน 5 วินาที

ส่วนที่สองคือ Profile ที่จัดอันดับกลุ่มคำสั่งตามผลกระทบ

# Profile
# Rank Query ID                        Response time  Calls  R/Call  V/M
# ==== =============================== ============== ====== ======= ====
#    1 0xABC123DEF456 SELECT orders...  1200.5 39.7%     482  2.4908  1.25
#    2 0x789GHI012JKL SELECT products.. 291.7  9.6%      156  1.8699  0.85
#    3 0xMNO345PQR678 UPDATE inventory. 245.3  8.1%       89  2.7562  2.10

Rank 1 คือคำสั่งที่ส่งผลกระทบมากที่สุด ใช้เวลารวม 39.7% ของเวลาทั้งหมด นี่คือเป้าหมายแรกที่ควรปรับปรุง คอลัมน์ V/M (Variance-to-Mean Ratio) บอกความสม่ำเสมอ ถ้าค่าสูง แปลว่าเวลาแต่ละครั้งต่างกันมาก อาจเกิดจาก Lock Contention หรือ Cache Miss

ส่วนที่สามคือ Query Detail ที่แสดงรายละเอียดของแต่ละกลุ่มคำสั่ง รวมถึง Histogram ของเวลา, ตัวอย่างคำสั่งจริง และ EXPLAIN Plan (ถ้ากำหนด --explain option ไว้)

บันทึก Log ลง Table แทน File

นอกจากเขียนลงไฟล์ MySQL ยังสามารถบันทึกข้อมูลลงตาราง mysql.slow_log ได้ ซึ่งมีข้อดีคือสามารถใช้คำสั่ง SQL วิเคราะห์ข้อมูลได้โดยตรง

SET GLOBAL log_output = 'TABLE';
SET GLOBAL slow_query_log = 'ON';

เมื่อตั้งค่าแล้ว สามารถ Query ข้อมูลจากตารางได้

-- ดูคำสั่งที่ช้าที่สุด 10 อันดับ
SELECT query_time, lock_time, rows_sent, rows_examined,
       CONVERT(sql_text USING utf8) AS sql_text
FROM mysql.slow_log
ORDER BY query_time DESC
LIMIT 10;

-- นับจำนวนคำสั่งช้าแยกตาม User
SELECT user_host, COUNT(*) AS slow_count,
       AVG(query_time) AS avg_time
FROM mysql.slow_log
GROUP BY user_host
ORDER BY slow_count DESC;

-- ดูคำสั่งช้าในช่วง 1 ชั่วโมงที่ผ่านมา
SELECT start_time, query_time, rows_examined,
       CONVERT(sql_text USING utf8) AS sql_text
FROM mysql.slow_log
WHERE start_time >= NOW() - INTERVAL 1 HOUR
ORDER BY query_time DESC;

ข้อเสียของการบันทึกลง Table คือมี Overhead สูงกว่าการเขียนลงไฟล์ เพราะต้อง INSERT ลงตารางทุกครั้ง อาจกระทบ Performance บน Production ที่มี Load สูง แนะนำให้ใช้ log_output = 'FILE' เป็นค่า Default และเปลี่ยนเป็น TABLE เมื่อต้องการวิเคราะห์เฉพาะช่วงเวลาสั้น ๆ

หากต้องการบันทึกทั้งสองแบบพร้อมกัน

SET GLOBAL log_output = 'FILE,TABLE';

จัดการขนาดไฟล์บันทึกบน Production

บน Production Server ที่มี Traffic สูง ไฟล์บันทึกอาจโตเร็วมากจนกินพื้นที่ดิสก์ การจัดการขนาดไฟล์จึงสำคัญ วิธีที่ปลอดภัยคือใช้ Log Rotation

Rotate ด้วย Flush Slow Logs

MySQL รองรับการ Rotate ไฟล์บันทึกโดยไม่ต้องหยุด Service ทำได้ด้วยการย้ายไฟล์เก่าแล้วสั่งให้ระบบสร้างไฟล์ใหม่

# ย้ายไฟล์ Log เก่า
sudo mv /var/log/mysql/slow.log /var/log/mysql/slow.log.$(date +%Y%m%d)

# สั่งให้ MySQL สร้างไฟล์ใหม่
mysqladmin -u root -p flush-logs

หรือรันจากภายใน MySQL Shell

FLUSH SLOW LOGS;

ตั้งค่า logrotate อัตโนมัติ

สร้างไฟล์ Configuration สำหรับ logrotate เพื่อให้ Rotate อัตโนมัติทุกวัน

sudo nano /etc/logrotate.d/mysql-slow

เพิ่มเนื้อหาดังนี้

/var/log/mysql/slow.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 640 mysql mysql
    postrotate
        /usr/bin/mysqladmin -u root -p'YourPassword' flush-logs
    endscript
}

การตั้งค่านี้จะ Rotate ไฟล์ทุกวัน เก็บไว้ 7 วัน บีบอัดไฟล์เก่า และสั่ง Flush อัตโนมัติหลัง Rotate สำหรับความปลอดภัยที่ดีกว่า แนะนำใช้ mysql_config_editor เก็บรหัสผ่านแทนการใส่ใน Script โดยตรง

ล้างข้อมูลใน slow_log Table

หากใช้ log_output แบบ TABLE ต้องล้างข้อมูลเก่าเป็นประจำเช่นกัน

-- ปิด Log ชั่วคราว
SET GLOBAL slow_query_log = 'OFF';

-- ล้างข้อมูลเก่ากว่า 7 วัน
DELETE FROM mysql.slow_log WHERE start_time < NOW() - INTERVAL 7 DAY;

-- หรือล้างทั้งหมด
TRUNCATE TABLE mysql.slow_log;

-- เปิด Log กลับ
SET GLOBAL slow_query_log = 'ON';

กรณีศึกษา — วิเคราะห์และแก้ไขคำสั่งช้า

สมมติว่าพบคำสั่งนี้ในไฟล์บันทึกที่ใช้เวลา 4.5 วินาที

# Query_time: 4.521234  Lock_time: 0.000089  Rows_sent: 25  Rows_examined: 2350000
SELECT o.order_id, o.total, c.email
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE o.status = 'completed'
  AND o.created_at >= '2024-06-01'
ORDER BY o.created_at DESC
LIMIT 25;

ขั้นตอนแรก วิเคราะห์ด้วย EXPLAIN

EXPLAIN SELECT o.order_id, o.total, c.email
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE o.status = 'completed'
  AND o.created_at >= '2024-06-01'
ORDER BY o.created_at DESC
LIMIT 25;

สมมติว่า EXPLAIN แสดง type=ALL สำหรับตาราง orders และ rows=2350000 แปลว่ากำลัง Full Table Scan ทั้งตาราง ปัญหาคือไม่มีดัชนีที่ครอบคลุม WHERE clause

ขั้นตอนที่สอง สร้าง Composite Index ที่เหมาะสม

ALTER TABLE orders ADD INDEX idx_status_created (status, created_at);

ดัชนีนี้ช่วยให้ระบบกรอง status = 'completed' ก่อน จากนั้นใช้ created_at ในดัชนีเดียวกันเพื่อกรองช่วงวันที่และเรียงลำดับ ทำให้ไม่ต้อง Scan ทั้งตาราง

ขั้นตอนที่สาม ตรวจสอบผลลัพธ์ด้วย EXPLAIN อีกครั้ง

EXPLAIN SELECT o.order_id, o.total, c.email
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE o.status = 'completed'
  AND o.created_at >= '2024-06-01'
ORDER BY o.created_at DESC
LIMIT 25;

หลังเพิ่มดัชนี type ควรเปลี่ยนเป็น ref หรือ range และ rows ลดลงอย่างมาก เวลาดำเนินการควรลดจาก 4.5 วินาทีเหลือไม่กี่มิลลิวินาที

ตัวชี้วัดสำคัญที่ควรติดตาม

นอกจากดูไฟล์บันทึกโดยตรง ควรติดตามตัวชี้วัดระดับ Server เพื่อประเมินสุขภาพโดยรวม

-- จำนวนคำสั่งช้าสะสมตั้งแต่ Start Server
SHOW GLOBAL STATUS LIKE 'Slow_queries';

-- อัตราส่วนคำสั่งช้าต่อคำสั่งทั้งหมด
SELECT
  (SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Slow_queries') AS slow,
  (SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Questions') AS total;

ค่า Slow_queries ที่เพิ่มขึ้นเร็วผิดปกติเป็นสัญญาณเตือนว่ามีปัญหาใหม่เกิดขึ้น ควรตั้ง Alert เมื่ออัตราส่วนเกินค่าที่กำหนด เช่น ถ้าคำสั่งช้าเกิน 1% ของคำสั่งทั้งหมดในช่วง 5 นาที

แนวปฏิบัติที่ดีสำหรับ Production

เปิดใช้งานเสมอ — Slow Query Log มี Overhead ต่ำมาก แนะนำให้เปิดไว้ตลอดบน Production ไม่ต้องเปิดเฉพาะตอนมีปัญหา การเปิดไว้ล่วงหน้าทำให้มีข้อมูลพร้อมวิเคราะห์ทันทีเมื่อเกิดปัญหา

ตั้ง logrotate ตั้งแต่วันแรก — อย่ารอจนดิสก์เต็ม ตั้ง logrotate ให้ Rotate ทุกวันและเก็บไว้ 7-14 วัน

วิเคราะห์เป็นประจำ — กำหนดตารางวิเคราะห์ไฟล์บันทึกอย่างน้อยสัปดาห์ละครั้ง ใช้ pt-query-digest สร้างรายงาน แล้วเปรียบเทียบกับสัปดาห์ก่อนเพื่อดูแนวโน้ม

ใช้ร่วมกับ Performance Schema — Slow Query Log จับเฉพาะคำสั่งที่ช้ากว่า Threshold แต่ Performance Schema ให้ข้อมูลสถิติรวมของทุกคำสั่ง การใช้ร่วมกันให้ภาพที่สมบูรณ์กว่า

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

สรุป

Slow Query Log เป็นเครื่องมือพื้นฐานที่ทรงพลังในการค้นหาคำสั่ง SQL ที่ทำงานช้า การเปิดใช้งานทำได้ง่ายทั้งผ่าน Configuration File และแบบ Runtime สิ่งสำคัญคือการตั้งค่า long_query_time ให้เหมาะสมกับลักษณะงาน การใช้เครื่องมือวิเคราะห์อย่าง mysqldumpslow สำหรับภาพรวมเบื้องต้นและ pt-query-digest สำหรับการวิเคราะห์เชิงลึก และการจัดการขนาดไฟล์ด้วย logrotate เมื่อวิเคราะห์แล้วพบคำสั่งที่ช้า ให้ใช้ EXPLAIN ตรวจสอบ Execution Plan แล้วแก้ไขด้วยการเพิ่มดัชนีหรือปรับโครงสร้างคำสั่งให้มีประสิทธิภาพ

แนะนำบริการ DE

การวิเคราะห์และปรับแต่งคำสั่งฐานข้อมูลที่ช้าต้องอาศัยเซิร์ฟเวอร์ที่ให้ Root Access เต็มรูปแบบเพื่อเข้าถึง Configuration File และไฟล์บันทึกได้โดยตรง Cloud VPS ของ DE เปิดให้ปรับแต่งทุกอย่างได้อิสระ มาพร้อม SSD Storage ที่ให้ IOPS สูง ช่วยให้ระบบจัดการฐานข้อมูลทำงานได้เต็มประสิทธิภาพ

สำหรับผู้ที่ต้องการฐานข้อมูลพร้อมใช้งานโดยไม่ต้องตั้งค่าเอง Cloud Hosting ของ DE มาพร้อมระบบจัดการฐานข้อมูลและ phpMyAdmin ที่ตั้งค่าให้เรียบร้อย เหมาะกับเว็บแอปพลิเคชันที่ต้องการความสะดวกในการจัดการข้อมูล

แท็กMySQL Database RDBMS