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

Categories

เมื่อแอปพลิเคชันเริ่มตอบสนองช้าลง หนึ่งในขั้นตอนแรกที่ 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 ที่ตั้งค่าให้เรียบร้อย เหมาะกับเว็บแอปพลิเคชันที่ต้องการความสะดวกในการจัดการข้อมูล