事务提交时抛出 Deadlock found when trying to get lock
怎么办
这是最常见的提交失败场景，不是代码写错了，而是 MySQL 在底层检测到两个或多个事务互相等待对方持有的锁，主动回滚其中一个（通常是执行时间更短的那个）来打破死锁。
关键点在于：MySQL 不会重试，应用层必须捕获这个错误并决定是否重试。
检查业务逻辑中是否有多表更新且顺序不一致——比如事务 A 先更新users再更新
orders，而事务 B 反过来，这是死锁温床 在应用中捕获
Deadlock found when trying to get lock错误码（1213），做有限次数重试（如 3 次），每次重试前加随机毫秒级延迟，避免重试风暴 用
SHOW ENGINE INNODB STATUS\G查看最近死锁详情，确认哪两条 SQL 在争抢哪些索引记录
COMMIT
报 Lock wait timeout exceeded
是什么情况
这不是死锁，而是某个事务卡住了太久，其他等待它释放锁的事务等不及超时了。常见于长事务、未提交的交互式会话，或大范围
UPDATE没走索引导致全表扫描锁表。
根本原因往往不在报错的那一句
COMMIT，而在前面的
BEGIN后某条语句执行太久或被阻塞。 用
SELECT * FROM information_schema.INNODB_TRX\G查看当前活跃事务，重点关注
TRX_STATE、
TRX_STARTED和
TRX_QUERY配合
SELECT * FROM information_schema.INNODB_LOCK_WAITS找出谁在等谁 设置合理超时：
innodb_lock_wait_timeout默认 50 秒，线上可调低至 10–20 秒，让问题更快暴露
事务里调用存储过程或触发器后提交失败，怎么定位
存储过程和触发器内部隐式开启子事务（尤其用了
START TRANSACTION或修改了
autocommit），容易与外层事务冲突，导致
COMMIT报
Cannot execute statement in a READ ONLY transaction或直接报错回滚。
MySQL 的事务边界对存储过程并不透明，尤其当过程里包含
INSERT/UPDATE/DELETE且未显式处理异常时。 检查过程体中是否误写了
START TRANSACTION或
SET autocommit = 0—— 这会让外层事务失效 过程内所有 DML 必须与调用它的事务共用同一上下文，不能自行
COMMIT；若真需独立提交，应改用
SAVEPOINT+
ROLLBACK TO SAVEPOINT在过程开头加
DECLARE EXIT HANDLER FOR SQLEXCEPTION，确保异常时能清理资源，但不要在 handler 里写
COMMIT
程序没报错但数据没生效，是不是事务没提交成功
最隐蔽的问题：事务看似“成功”返回，但实际因连接异常中断、客户端崩溃、或网络丢包，导致
COMMIT命令根本没发到 MySQL。服务端日志里查不到该事务的
COMMIT记录，但客户端日志显示“提交完成”。
这种问题无法靠 MySQL 自身恢复，必须依赖应用层的幂等设计和外部校验。
在事务提交后，立刻执行一条带唯一约束的轻量级验证查询（如SELECT COUNT(*) FROM t WHERE id = ? AND status = 'done'），确认变更已落库 关键业务字段建议加
updated_at时间戳，并在提交后比对数据库时间与本地时间，偏差过大即告警 避免依赖单一连接生命周期管理事务；使用连接池时，务必配置
autoReconnect=false并启用
testOnBorrow，防止复用脏连接
事务恢复没有银弹。真正难的不是知道要
ROLLBACK或重试，而是判断「这次失败是否可安全重试」「重试会不会造成状态重复」——这取决于你的业务语义，而不是 MySQL 的错误码。
