MySQL 5.7 服務管理權威指南：日志體系、多實例與 DTrace 監控

MySQL 5.7 服務管理權威指南：日志體系、多實例與 DTrace 監控

本文基於 MySQL 官方參考手冊第 5 章，系統整理 MySQL 服務端核心管理知識，涵蓋日志體系、多實例部署、動態追蹤三大塊，適合 DBA 速查與深度學習。

一、MySQL 服務端架構總覽

mysqld 是單進程多線程架構。核心線程包括：連接管理線程、用戶線程（處理查詢）、後台線程（InnoDB Master/IO/Purge、Binlog Dump 等）。理解線程模型是性能調優基礎。

二、五大日志體系深度解析

MySQL 擁有五類日志，各司其職：

2.1 日志輸出目標：FILE vs TABLE vs NONE

log_output 控制 General/Slow Log 寫入方式：

• FILE（默認）：寫文件，性能好，便於輪轉。
• TABLE：寫 mysql.general_log/slow_log 表，可用 SQL 查詢、遠程訪問，但寫入開銷大，不支持分區、鎖表、事務、備份。
• NONE：不記錄。

生產建議：General Log 關閉；Slow Log 用 FILE，定期 FLUSH LOGS 輪轉並歸檔分析。

2.2 Binary Log 核心機制

• 三種格式：STATEMENT（默認，語句級）、ROW（行級）、MIXED（混合）。ROW 最安全，MIXED 折中。
• 寫入時機：事務提交前，釋放鎖之前寫入 Binlog（組提交優化）。非事務表語句結束即寫。
• 同步策略：sync_binlog=1 最安全（每次提交 fsync），配合 innodb_support_xa=ON 保證崩潰後主從一致。性能敏感可設 >1 或 0（依賴 OS 刷盤）。
• 清理策略：expire_logs_days 自動過期；PURGE BINARY LOGS 手動清理。切勿手刪文件，會導致索引文件錯亂。

2.3 Slow Query Log 進階控制

• log_throttle_queries_not_using_indexes：限制無索引查詢日志寫入頻率（每 60 秒上限），防止日志爆增。
• log_slow_admin_statements：記錄管理命令（OPTIMIZE, ALTER 等）。
• 從庫默認不寫 Slow Log，需開啟 log_slow_slave_statements。

三、單機多實例部署

通過不同 datadir、port、socket、pid-file、log-error 隔離多個 mysqld 進程。推薦使用 mysqld_multi 管理，或容器化（Docker/K8s）實現資源隔離與編排。

四、DTrace 動態追蹤：生產環境的「顯微鏡」

MySQL 5.6+ 內建 DTrace Provider (mysqld)，提供 60+ 探針覆蓋連接、查詢解析、執行、行級操作、鎖、排序、網絡、鍵緩存等全鏈路。典型用法：

# 統計查詢延遲分佈
dtrace -n 'mysql*:::query-start { self->ts = timestamp } 
mysql*:::query-done /self->ts/ { @[probename] = quantize(timestamp - self->ts); self->ts = 0 }'

適用於 Solaris、macOS、FreeBSD、Linux (SystemTap 兼容)。生產環境無侵入式診斷慢查詢、鎖爭用、IO 熱點的利器。

五、運維金句

1. 日志默認關閉，按需開啟，Slow Log 必開。
2. Binlog 格式生產建議 MIXED 或 ROW，sync_binlog=1 配合 XA 事務。
3. 定期 FLUSH LOGS 配合備份策略，避免單個日志文件過大。
4. 用 mysqlbinlog 解析 Binlog 做 PITR 或異構同步。
5. 多實例隔離資源，避免單點故障波及全業務。