应捕获死锁错误（1213）并重试，检查多表更新顺序是否一致，用SHOW ENGINE INNODB STATUS分析死锁，调低innodb_lock_wait_timeout，避免存储过程中隐式开启事务，确保幂等性与提交后验证。
事务提交时抛出 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 的错误码。
