MySQL死锁应急指南：5分钟快速定位与恢复实战

凌晨三点，手机突然响起刺耳的告警声——线上核心服务出现大量"Deadlock found when trying to get lock"错误。作为值班工程师，此刻需要的不是长篇大论的原理解析，而是能立即止血的实战方案。本文将分享如何利用MySQL内置工具在5分钟内完成死锁定位、进程终止和服务恢复的全套操作流程。

1. 死锁紧急响应流程

1.1 第一步：确认死锁特征

当出现死锁时，典型的现象包括：

• 应用日志中出现"Deadlock found when trying to get lock"错误
• 数据库监控显示事务等待时间突增
• 应用接口响应超时率飙升

快速验证命令：

sql复制SHOW ENGINE INNODB STATUS\G

在输出中搜索"LATEST DETECTED DEADLOCK"部分，可以获取最近发生的死锁详情。

1.2 第二步：锁定问题会话

通过information_schema库快速定位阻塞源：

sql复制SELECT 
    r.trx_id waiting_trx_id,
    r.trx_mysql_thread_id waiting_thread,
    r.trx_query waiting_query,
    b.trx_id blocking_trx_id,
    b.trx_mysql_thread_id blocking_thread,
    b.trx_query blocking_query
FROM information_schema.innodb_lock_waits w
INNER JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id
INNER JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id;

关键字段说明：

1.3 第三步：安全终止阻塞进程

获取到blocking_thread后，执行：

sql复制KILL [blocking_thread];

注意：优先终止长时间运行(>30s)的事务，避免影响正常业务事务

2. information_schema深度应用技巧

2.1 关键系统表解析

MySQL提供多个监控表用于死锁分析：

2.2 高效查询组合

推荐使用以下联查语句快速定位问题：

sql复制SELECT 
    r.trx_id waiting_trx,
    r.trx_mysql_thread_id waiting_thread,
    r.trx_query waiting_query,
    b.trx_id blocking_trx,
    b.trx_mysql_thread_id blocking_thread,
    b.trx_query blocking_query,
    TIMESTAMPDIFF(SECOND, b.trx_started, NOW()) blocking_time
FROM information_schema.innodb_lock_waits w
INNER JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id
INNER JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id
ORDER BY blocking_time DESC;

2.3 自动化监控方案

配置定期执行的监控脚本：

bash复制#!/bin/bash
DEADLOCK=$(mysql -e "SHOW ENGINE INNODB STATUS\G" | grep -c "LATEST DETECTED DEADLOCK")
if [ $DEADLOCK -gt 0 ]; then
    # 触发告警并保存现场
    mysql -e "SHOW ENGINE INNODB STATUS\G" > /tmp/deadlock_$(date +%s).log
    send_alert "MySQL deadlock detected"
fi

3. 死锁预防最佳实践

3.1 事务设计原则

• 控制事务粒度：单个事务处理不超过1000行数据
• 统一访问顺序：多表操作时固定表访问顺序
• 设置超时时间：innodb_lock_wait_timeout=50(默认50秒)

3.2 索引优化建议

常见死锁诱因及解决方案：

3.3 代码层防护

在应用层添加重试逻辑：

python复制def safe_update():
    retries = 3
    while retries > 0:
        try:
            execute_update()
            break
        except DeadlockError:
            retries -= 1
            time.sleep(random.uniform(0.1, 0.5))

4. 事后分析与持续改进

4.1 死锁日志分析

从SHOW ENGINE INNODB STATUS输出中提取关键信息：

1. 事务1和事务2持有的锁
2. 等待的资源
3. 最后执行的SQL语句

分析模式：

code复制*** (1) TRANSACTION:
TRANSACTION 12345, ACTIVE 10 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 111, OS thread handle 0x7f1a2c0b1700, query id 222 10.0.0.1 user updating
UPDATE table1 SET col1=val1 WHERE id=100
*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 333 page no 3 n bits 72 index `PRIMARY` of table `db1`.`table1` trx id 12345 lock_mode X locks rec but not gap
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 333 page no 4 n bits 72 index `idx_col2` of table `db1`.`table1` trx id 12345 lock_mode X locks rec but not gap waiting

4.2 长期监控策略

建议部署以下监控指标：

• innodb_deadlocks：死锁计数器
• innodb_row_lock_time_avg：平均行锁等待时间
• innodb_row_lock_waits：行锁等待次数

Prometheus配置示例：

yaml复制- name: mysql_deadlocks
  rules:
  - alert: HighDeadlockRate
    expr: rate(mysql_global_status_innodb_deadlocks[1m]) > 0
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "MySQL deadlock detected (instance {{ $labels.instance }})"

在实际处理某电商平台死锁问题时，我们发现凌晨批量更新用户积分时频繁触发死锁。通过分析发现是事务中同时更新了用户表和积分明细表，但不同服务中这两个表的更新顺序不一致。统一为"先用户表后积分表"的访问顺序后，死锁发生率下降了90%。