死锁导致事务被MySQL主动回滚，应用需捕获ERROR 1205并指数退避重试；COMMIT不静默失败，所谓“提交失败”多因连接异常、autocommit配置错误或DDL/存储过程破坏事务边界；排查须查INNODB_TRX等视图并开启innodb_print_all_deadlocks。
事务提交时提示 ERROR 1205 (40001): Deadlock found when trying to get lock
这是最常见的提交失败原因，不是代码写错了，而是两个或多个事务互相等待对方持有的锁，MySQL 主动杀掉其中一个事务回滚以打破僵局。
关键点在于：被选为 victim 的事务会收到这个错误，它必须由应用层捕获并重试，MySQL 不会自动重试。
- 检查业务逻辑中是否有多表更新且顺序不一致（比如事务 A 先更新
users再更新orders，事务 B 反过来） - 尽量缩短事务持续时间：把非数据库操作（如 HTTP 调用、文件读写）移出事务块
- 统一多表操作顺序：所有涉及
users和orders的事务都按相同顺序加锁 - 在应用中捕获
1205错误码，做指数退避重试（最多 3 次），避免雪崩
COMMIT 执行后返回成功，但数据没生效
看起来像“提交失败”，其实是客户端没正确处理 autocommit 模式或连接状态。MySQL 的 COMMIT 命令本身不会静默失败——只要没报错，就已持久化。
常见真实原因：
- 连接被意外断开（如网络闪断、中间件超时），客户端以为 COMMIT 成功，其实服务端已回滚
- 使用了连接池但未正确配置
testOnBorrow或validationQuery，导致拿到一个已失效的连接 - 应用开启了 autocommit，却手动执行了
BEGIN，后续又没显式COMMIT，连接关闭时自动回滚 - 事务内执行了 DDL（如
ALTER TABLE），MySQL 会隐式提交当前事务，后续语句不在原事务中
事务中调用存储过程后 COMMIT 失败
存储过程内部如果包含 START TRANSACTION、COMMIT 或 ROLLBACK，会破坏外部事务的一致性，MySQL 直接报错 ERROR 1305 (42000): SAVEPOINT does not exist 或直接拒绝 COMMIT。
根本原则：存储过程默认不应管理事务边界，只负责业务逻辑。
- 确保存储过程中没有
COMMIT/ROLLBACK语句（除非明确设计为自治事务，且 MySQL 版本 ≥ 8.0.27 并启用innodb_autocommit相关配置） - 若必须在过程内控制事务，请用
SAVEPOINT+ROLLBACK TO SAVEPOINT替代完整提交 - 调用方统一管理事务，存储过程只抛出异常（
SIGNAL SQLSTATE '45000'），由上层决定是否回滚
查看事务实际状态和锁信息
不能只看应用日志或客户端返回，得进 MySQL 查真实状态。以下命令是排查核心：
SELECT * FROM information_schema.INNODB_TRX\G
重点关注 TRX_STATE（是否卡在 LOCK WAIT）、TRX_STARTED（事务开始时间）、TRX_QUERY（当前执行语句）。
再结合锁视图定位阻塞源：
SELECT * FROM information_schema.INNODB_LOCK_WAITS\G
SELECT * FROM information_schema.INNODB_LOCKS\G
注意：INNODB_LOCKS 在 MySQL 8.0.18+ 已废弃，改用 performance_schema.data_locks，但字段名和结构有变化，查之前先确认版本。
真正难的不是发现死锁，而是复现和固化修复——很多事务问题只在高并发下偶发，日志里留不下完整上下文。所以线上务必开启 innodb_print_all_deadlocks = ON，让死锁信息写入 error log，而不是只丢给客户端。
