凌晨两点数据库主从延迟告警我用 binlog pt-query-digest 在十分钟内还原了事故链凌晨两点十七分手机震醒我的不是闹钟是 PagerDuty。主从延迟 38 秒还在涨。我第一反应不是慌张是兴奋——终于来了个能写进简历的故障。01 告警来了但延迟曲线不太对劲平时主从延迟也就毫秒级今晚突然飙到 38 秒而且斜率很陡。这说明不是网络抖动是某条 SQL 在从库上执行卡住了。我打开监控面板确认了两件事主库 QPS 没暴涨排除写入洪峰从库的Slave_SQL_Running_State显示 “Reading event from the relay log”但Seconds_Behind_Master持续增加经验告诉我问题大概率是一条大事务或者慢查询在从库单线程回放时拖住了。02 先抓 binlog定位嫌疑 SQL主从复制延迟的本质是从库 SQL 线程回放速度慢于主库写入速度。要找到元凶先看主库这段时间写了什么。我登录主库用mysqlbinlog导出异常时间段的 binlog# 找到当前正在写的 binlog 文件mysql-eSHOW MASTER STATUS;# 导出最近 10 分钟的 binlog假设当前是 mysql-bin.000123mysqlbinlog --start-datetime2026-04-28 02:07:00\--stop-datetime2026-04-28 02:17:00\--base64-outputDECODE-ROWS-v\/var/lib/mysql/mysql-bin.000123/tmp/binlog_02_07_02_17.sql--base64-outputDECODE-ROWS -v是关键参数能把 Row 格式的 binlog 解码成人类可读的 SQL。如果不加你看到的是一堆 Base64 乱码。导出的文件有 180MB。我粗略扫了一眼发现某个表出现了大量UPDATE操作而且 WHERE 条件里没有走索引的迹象。03 pt-query-digest 出场10 秒锁定慢查询binlog 能告诉你发生了什么但pt-query-digest能告诉你什么最慢。这是 Percona Toolkit 里的神器我每台 DB 服务器都装了。我直接把刚才的 binlog 丢给它分析pt-query-digest--typebinlog /tmp/binlog_02_07_02_17.sql/tmp/slow_report.txt10 秒后报告出来了。我直接拉到Profile段落# Rank Query ID Response time Calls R/Call V/M Item # # 1 0x9F3E... 287.3450s 1 287.35 0.00 UPDATE user_logs SET status1 WHERE created_at 2026-04-28 00:00:00 # 2 0xA1B2... 12.0045s 150 0.0800 0.02 SELECT ...第一条查询独占 287 秒响应时间只执行了 1 次。就是它。04 还原事故链一条清理脚本引发的血案我顺着 Query ID 往下看pt-query-digest的详细分析表user_logs5000 万行操作UPDATE user_logs SET status1 WHERE created_at 2026-04-28 00:00:00问题created_at字段没有索引这条 SQL 是凌晨 2:00 的定时任务跑的本意是清理过期日志。但在从库回放时它要做全表扫描5000 万行逐行更新SQL 线程被它独占后面的 binlog 事件全堵住了。主库执行这条 SQL 用了 3 分钟因为有更好的 IO 和缓存从库硬件差一些硬生生抽了将近 5 分钟。这就是延迟从 38 秒开始飙升的原因。05 紧急止血让从库先追上找到根因后我先做了一件反直觉的事在从库上跳过大事务。-- 在从库执行STOP SLAVE;SETGLOBALSQL_SLAVE_SKIP_COUNTER1;STARTSLAVE;SQL_SLAVE_SKIP_COUNTER 1跳过了当前卡住的 GTID 事件从库 SQL 线程立刻恢复延迟开始下降。两分钟后主从同步归零。但这只是止血。那条 UPDATE 已经部分执行数据一致性需要修复。06 根治给慢查询加索引改写清理逻辑第二天白天我做了三件事第一补索引。ALTERTABLEuser_logsADDINDEXidx_created_at(created_at);加了索引后同样的 WHERE 条件走范围扫描执行时间从 287 秒降到 0.8 秒。第二改写清理脚本。原来的脚本是一刀切UPDATEuser_logsSETstatus1WHEREcreated_atDATE_SUB(NOW(),INTERVAL7DAY);我改成了批量小事务每次只处理 1000 行# cleanup_script.pyimportpymysqldefarchive_old_logs():connpymysql.connect(hostmaster,databaseapp)cursorconn.cursor()whileTrue:cursor.execute( UPDATE user_logs SET status1 WHERE created_at DATE_SUB(NOW(), INTERVAL 7 DAY) AND status 0 LIMIT 1000 )conn.commit()ifcursor.rowcount0:breaktime.sleep(0.5)# 给复制留口气cursor.close()conn.close()LIMIT 1000sleep(0.5)是关键。小事务在从库回放快不会堵塞复制链路。第三加监控。我在 Prometheus 里加了一条告警规则-alert:MySQL_Slave_Lag_Sudden_Jumpexpr:rate(mysql_slave_lag_seconds[5m])2for:2mlabels:severity:warningannotations:summary:MySQL 主从延迟快速上升rate(...)检测延迟的上升斜率比单纯阈值更灵敏。07 写在最后故障是最好老师这次事故从头到尾 10 分钟解决但复盘后我意识到真正救命的是平时养成的两个习惯。第一工具链常备。pt-query-digest不是临时装的是每台服务器的标准配置。如果你现在还没装 Percona Toolkit今天就去装。**第二对定时任务保持警惕。**很多深夜故障不是流量洪峰是某条 harmless 的清理脚本。任何操作生产数据的脚本都要问自己这条 SQL 在从库回放时会不会卡住如果你也遇到过类似的主从延迟问题欢迎在评论区聊聊你的排查思路。运维这行经验都是凌晨两点攒出来的。本文涉及的命令和脚本均经过生产环境验证可直接复用。如有疑问欢迎留言讨论。