現象描述

慢查詢日誌中反複出現：

# Time: 130823 13:56:08
# User@Host: repl[repl] @ slave [10.x.x.x]
# Query_time: 9.000833  Lock_time: 0.000000  Rows_sent: 1  Rows_examined: 1
SET timestamp=1377237368;
# administrator command: Binlog Dump;

每次從庫拉取 Binlog 都被記錄為「慢查詢」，佔滿日誌干擾分析。

根因分析

• Binlog Dump 是從庫 IO 線程向主庫請求 Binlog 事件的持久命令，執行時間等於從庫等待新事件的時間（通常為秒級）。
• MySQL 5.1.x 版本將「管理命令」（含 Binlog Dump）納入慢查詢日誌範圍，由參數 log_slow_admin_statements 控制（默認 OFF，但 5.1.49 等特定版本行為異常）。
• 此類記錄無優化價值，純屬干擾。

  解決方案

  方法一：關閉管理命令慢查詢記錄（推薦）

  [mysqld]
  log_slow_admin_statements = 0
  

  • 需重啟 MySQL 生效（5.1 版本不支持動態修改）。
  • 5.6+ 版本可動態設置：SET GLOBAL log_slow_admin_statements = OFF;。

  方法二：調大慢查詢閾值（治標不治本）

  SET GLOBAL long_query_time = 30;  -- 單位秒
  

  • 會漏掉真正的慢查詢，不推薦。

  方法三：升級 MySQL 版本

  • MySQL 5.5+ 已修復此行為，Binlog Dump 不再受 log_slow_admin_statements 影響（默認不記錄）。
  • 長期規劃應升級至 5.7/8.0 獲得完善的慢查詢分類與性能架構。

  驗證修復

  -- 重啟後觀察慢查詢日誌 10 分鐘
  tail -f /var/lib/mysql/slow.log | grep -i "binlog dump"
  -- 應無新記錄
  

  相關參數補充

  參數	說明	動態修改
  log_slow_admin_statements	是否將 ALTER TABLE、ANALYZE、Binlog Dump 等管理命令記入慢查詢	5.6+ 支持，5.1 不支持
  log_slow_slave_statements	從庫 SQL 線程執行的語句是否記入慢查詢（5.6+）	支持
  slow_query_log	總開關	支持
  long_query_time	慢查詢閾值（秒，支持微秒）	支持

  總結

  MySQL 5.1.x 特定版本將 Binlog Dump 錯誤歸類為慢管理命令。設置 log_slow_admin_statements=0 並重啟即可徹底屏蔽。長期應升級版本並建立慢查詢分析規範（pt-query-digest、mysqldumpslow），專注於真正的業務慢 SQL 優化。