应使用tail -f实时监听mysql错误日志，配合awk '/^deadlock/,/^$/'精准提取完整死锁块，动态获取日志路径、处理utf-8编码、兜底监控rotated日志，避免依赖innodb_trx等易漏检的表。
如何从MySQL错误日志中实时提取死锁事件
MySQL本身不提供“死锁发生即报警”的接口，但会在error.log里写入形如Deadlock found when trying to get lock的记录——这是唯一可靠、无需开启性能_schema或额外权限的源头。关键不是“解析所有日志”，而是用tail -F持续监听+精准匹配，避免漏报或误触发。
常见错误是直接grep "Deadlock"全量扫日志，既吃CPU又延迟高；更糟的是忽略事务ID和SQL片段的跨行特性，导致提取出空或截断的内容。
- 必须用
awk或sed处理多行块：死锁日志是分段结构，含*** (1) TRANSACTION、*** (2) TRANSACTION、*** WE ROLL BACK TRANSACTION (2)等标记 - 推荐用
awk '/^Deadlock/,/^$/'匹配从“Deadlock”开始到下一个空行结束的完整块（注意MySQL 8.0+默认日志格式已改用JSON，需先确认log_error_verbosity=3且未启用log_error_services="log_filter_dragnet; log_sink_json"） - 生产环境务必加
timeout 30s保护，防止tail -F卡死在rotated日志上
Shell脚本如何构造可执行的死锁告警逻辑
告警不是简单发邮件，核心是“去重+限流+携带上下文”。同一死锁反复刷屏毫无意义，而丢掉关键SQL会导致DBA无法定位问题。
一个可用的最小闭环包含三步：捕获块 → 提取事务SQL → 判重并触发通知。
- 用
md5sum对完整死锁块哈希，存入临时文件/tmp/deadlock.lasthash，每次比对避免重复告警（10分钟内相同死锁只报一次） - 用
awk '/query:/ {print $NF}'提取每条事务最后执行的SQL（注意MySQL日志中SQL可能被截断，优先取ROLLING BACK前最近的query:行） - 告警命令建议封装为函数：
send_alert() { echo "$1" | mail -s "[DB] Deadlock on $(hostname)" admin@team.com; }，便于后续替换为Webhook或企业微信
为什么不能直接依赖INFORMATION_SCHEMA.INNODB_TRX
INFORMATION_SCHEMA.INNODB_TRX只能看到“当前持有锁的事务”，而死锁发生后，MySQL已自动回滚其中一个事务，此时查该表大概率为空——你看到的是“死锁之后”，不是“死锁之时”。
更隐蔽的问题是权限：该表需要PROCESS权限，而很多生产账号被严格限制，但读error.log只需文件系统读取权（由MySQL进程属主控制，通常DBA可控）。
- 监控脚本若依赖
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX，会漏掉90%以上的死锁事件 - 即使配合
INNODB_LOCK_WAITS轮询，也存在竞态窗口：从检测到锁等待，到死锁被触发并回滚，中间可能不到100ms - 真正有效的做法是“事后溯源”，而非“事中拦截”——日志是唯一完整、异步、持久化的证据源
实际部署时最容易被忽略的三个细节
脚本能跑通不等于能在线上稳住。以下三点不处理，一周内必出问题。
- 日志路径硬编码：MySQL配置中
log_error可能指向/var/log/mysql/error.log，也可能指向/data/mysql/hostname.err，必须从mysql -e "SELECT @@log_error;"动态获取 - 字符集陷阱：部分MySQL日志含UTF-8特殊符号（如emoji注释），
LANG=C环境下awk可能截断，应在脚本开头显式设置export LANG=en_US.UTF-8 - rotated日志丢失：
logrotate每天切日志时，tail -F可能短暂中断。必须用inotifywait -m -e moved_to /var/log/mysql/ | while read ...; do tail -n0 -f ${newfile}; done做兜底切换
死锁本身不可怕，可怕的是告警没带SQL、没标时间、没留堆栈。日志解析脚本的价值不在“有没有”，而在“能不能让DBA打开邮件就立刻复现问题”。
