1. 大厂MySQL死锁问题实战解析上周排查一个线上死锁问题差点让我享年25岁这个看似简单的数据库问题背后藏着不少门道。作为每天处理上亿请求的电商平台DBA我们遇到的死锁场景比教科书复杂十倍不止。今天就把大厂处理MySQL死锁的完整方法论拆解给你看包含那些官方文档不会写的实战技巧。死锁不是简单的锁等待超时而是两个事务互相持有对方需要的资源形成闭环等待。就像两辆车在窄桥相遇谁都不肯倒车最后交警(数据库引擎)只能强制吊销一方驾照(回滚事务)。但大厂的高并发场景下死锁往往涉及十几张表、嵌套事务和分布式锁排查难度指数级上升。2. 死锁现场还原与分析2.1 典型死锁场景复现我们最近遇到的真实案例订单支付完成后同时触发库存扣减和积分增加操作。两个事务的执行时序如下-- 事务A BEGIN; UPDATE inventory SET stock stock - 1 WHERE item_id 100; -- 持有item_id100的行锁 UPDATE user_points SET points points 100 WHERE user_id 1; -- 事务B BEGIN; UPDATE user_points SET points points 200 WHERE user_id 1; -- 持有user_id1的行锁 UPDATE inventory SET stock stock - 2 WHERE item_id 100;当这两个事务并发执行时事务A持有item_id100的锁等待user_id1的锁事务B正好相反典型的交叉等待死锁。MySQL检测到后会强制回滚其中一个事务报错Deadlock found when trying to get lock。2.2 大厂死锁分析三板斧实时监控配置监控系统抓取show engine innodb status输出关键指标包括死锁频率(次/分钟)涉及表及索引事务等待时间日志分析死锁发生时MySQL会记录详细日志重点看LATEST DETECTED DEADLOCK ------------------------ 2024-03-20 14:23:11 0x7f8e4418a700 *** (1) TRANSACTION: TRANSACTION 1823, ACTIVE 0 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)可视化工具使用pt-deadlock-logger工具将死锁日志图形化展示清晰看到锁等待环。3. 大厂级解决方案3.1 事务设计规范统一访问顺序所有事务必须按照固定顺序访问表。比如先user表后order表避免交叉等待。重要在代码审查时加入顺序检查这是预防死锁最有效的手段短事务原则单个事务不超过5条SQL执行时间控制在50ms内。我们通过AOP切面监控事务时长超时自动告警。锁升级策略查询使用FOR UPDATE明确要加锁批量操作使用LOCK IN SHARE MODE减少锁冲突热点数据使用SELECT ... SKIP LOCKED跳过已锁记录3.2 索引优化技巧错误索引是死锁的隐形杀手。某次我们修改了联合索引顺序后死锁率下降90%-- 错误示例高频更新的status字段放在联合索引首位 ALTER TABLE orders ADD INDEX idx_status_user (status, user_id); -- 正确做法区分度高的字段在前 ALTER TABLE orders ADD INDEX idx_user_status (user_id, status);索引设计黄金法则区分度高的列在前避免更新频繁的列做索引联合索引不超过3列3.3 重试机制实现死锁无法100%避免必须有完善的重试策略。我们的Java实现方案Retryable(maxAttempts3, backoffBackoff(delay100)) public void processPayment(Long orderId) { // 业务逻辑 }关键参数最大重试次数3次退避策略指数退避(100ms, 200ms, 400ms)异常过滤仅对死锁异常重试4. 高级场景解决方案4.1 分布式死锁处理跨服务死锁更棘手我们采用以下方案全局事务ID通过Snowflake生成唯一traceId贯穿所有服务锁超时控制所有分布式锁设置5秒超时死锁检测定期扫描锁等待图发现环路主动释放4.2 热点行优化秒杀场景下的热点商品更新方案UPDATE inventory SET stock stock - 1 WHERE item_id 100 AND stock 1; -- 乐观锁控制配合Redis预减库存最终数据库QPS从5000降到200。5. 监控与应急方案5.1 死锁监控看板我们使用的Prometheus监控指标mysql_innodb_deadlocksmysql_innodb_row_lock_waitsmysql_innodb_lock_wait_time配置告警规则alert: MySQLDeadlockHigh expr: rate(mysql_innodb_deadlocks[1m]) 5 for: 5m5.2 应急预案死锁突增时的处理流程立即摘除异常实例分析死锁日志定位热点表临时方案增加锁超时时间SET GLOBAL innodb_lock_wait_timeout10;长期方案修改事务逻辑或索引6. 实战中的血泪教训隐式锁陷阱外键约束会自动加锁曾导致我们级联死锁。解决方案SET FOREIGN_KEY_CHECKS0; -- 事务开始前关闭 -- 业务SQL SET FOREIGN_KEY_CHECKS1;Gap锁误区RR隔离级别下范围查询会加Gap锁。某次全表更新导致整个表被锁死改用RC隔离级别后解决。连接池配置连接数不足会导致事务等待放大死锁概率。建议配置# Druid配置 initialSize10 maxActive50 maxWait1000死锁问题就像数据库系统的免疫反应适度的死锁说明系统在高并发下正常工作。我们的经验值是控制在0.1次/分钟以下超过这个阈值就需要深入排查。记住好的解决方案不是消灭死锁而是把它控制在合理范围。