Troubleshooting MySQL: Xử Lý Sự Cố Database Từ Cơ Bản Đến Nâng Cao

Giới Thiệu

3 giờ sáng, điện thoại rung: "API đang timeout hàng loạt, khách hàng không đặt được đơn." Bạn SSH vào server, mở MySQL client lên — và giờ thì sao? Đây chính là lúc kỹ năng troubleshooting khác hẳn với việc "biết SQL" hay "biết index". Troubleshooting là khả năng, trong vài phút, trả lời được: vấn đề nằm ở hạ tầng hay ở database, đang có bao nhiêu kết nối, ai đang chạy gì, query nào đang chặn ai, và mình có nên KILL nó không.

Bài viết này là một playbook xử lý sự cố theo từng bước, đi từ cơ bản (nhìn metric hạ tầng CPU/Memory trước, đếm connection, đọc process list) đến nâng cao (phân biệt query chậm với query bị khoá, đọc deadlock, dùng đúng lệnh FLUSH). Nếu bạn chưa đọc, hai bài trước trong khoá học sẽ hữu ích để hiểu sâu hơn phần "vì sao": Tối ưu query MySQL với Index (cách sửa tận gốc một query chậm) và MySQL Monitoring (cách giám sát chủ động, trước khi sự cố xảy ra). Bài này tập trung vào tình huống ngược lại: sự cố đã xảy ra rồi, cần xử lý ngay bây giờ.

Troubleshooting Khác Gì Monitoring?

Một phân biệt quan trọng trước khi bắt đầu:

	Monitoring	Troubleshooting
Thời điểm	Liên tục, chủ động	Khi sự cố đã xảy ra
Mục tiêu	Phát hiện xu hướng, cảnh báo sớm	Xác định nguyên nhân ngay lập tức và khôi phục dịch vụ
Công cụ chính	Dashboard, Prometheus/Grafana, slow query log tổng hợp	SHOW PROCESSLIST, EXPLAIN ANALYZE, SHOW ENGINE INNODB STATUS trực tiếp
Câu hỏi điển hình	"Xu hướng connection tuần này thế nào?"	"Ngay lúc này ai đang chặn ai?"

Nói cách khác: monitoring là radar, troubleshooting là phòng cấp cứu. Bài này là quy trình cho phòng cấp cứu.