事务提交时提示 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，而不是只丢给客户端。
