MySQL如何解决锁等待超时异常_捕获MySQL Error 1205错误

Error 1205应优先判断事务是否真需重试，因MySQL已选择代价小的事务回滚；仅在幂等、可安全重试场景下限次重试，并须通过错误码精准捕获而非字符串匹配。MySQL死锁报错Error 1205到底该不该重试遇到Error 1205（Deadlock found when trying to get lock），第一反应不是"赶紧捕获重试"，而是先确认：这个事务是不是真的该被回滚。MySQL主动杀掉的是**代价更小的那个事务**，它已经帮你做了选择------强行重试反而可能放大冲突。常见错误现象：ERROR 1205 (40001): Deadlock found when trying to get lock 突然出现，但业务日志里没明显并发写同一行；或者重试后又立刻报一次Error 1205，形成循环。只在明确知道事务可安全重试时才加重试逻辑（比如幂等更新用户积分、扣减库存且已校验余额）不要对INSERT ... SELECT、UPDATE多表关联、或含子查询的事务盲目重试------这类语句锁范围难预估，重试大概率再撞上应用层重试建议限制1--2次，间隔随机化（如50ms--200ms），避免所有客户端同步重试造成雪崩如何快速定位哪两条SQL在互相锁住Error 1205日志本身不直接告诉你谁锁了谁，但MySQL会在错误日志里附上最近的死锁信息（需开启innodb_print_all_deadlocks=ON）。关键看WAITING FOR THIS LOCK TO BE GRANTED和HOLDS THE LOCK(S)两段。使用场景：线上突发大量Error 1205，要立刻判断是业务逻辑缺陷，还是索引缺失导致锁升级。检查死锁日志中涉及的表是否缺少合适索引------例如UPDATE user SET status=1 WHERE name='xxx'没走索引，会锁全表，极易引发死锁注意REPLACE INTO、INSERT ... ON DUPLICATE KEY UPDATE在唯一键冲突时会加next-key lock，和普通UPDATE行为不同用SELECT * FROM performance_schema.data_locks（MySQL 8.0+）实时查当前锁，但别在高峰期频繁查，开销不小为什么加了索引还是死锁：UPDATE顺序很关键即使每条UPDATE都走了索引，只要两个事务以不同顺序更新同一组行，照样死锁。比如事务A先改id=1再改id=2，事务B反过来，就构成经典环形等待。 RedClaw 百度推出的手机端万能AI Agent助手