MySQL事务失败主要由锁冲突、主键/唯一键冲突、事务过大或内存不足、隐式提交与自动提交干扰等多因素导致；需针对性优化锁等待、索引设计、事务粒度及DDL使用规范。
MySQL事务失败，通常不是单一原因导致的，而是由锁冲突、SQL语法或逻辑错误、资源限制、隔离级别影响等多方面因素共同作用的结果。快速定位关键点，比盲目查日志更有效。
锁等待超时（Lock wait timeout）
这是生产环境中最常遇到的事务失败原因之一。当一个事务长时间持有某行或表的锁，而另一个事务试图获取相同资源时，就会触发等待；超过innodb_lock_wait_timeout设定值（默认50秒）后，后发起的事务会被强制回滚，并报错：ERROR 1205 (HY000): Deadlock found when trying to get lock... 或 ERROR 1205 / ERROR 1213。
- 用 SHOW ENGINE INNODB STATUS\G 查看最近死锁详情，重点关注 LATEST DETECTED DEADLOCK 区域
- 检查是否在事务中执行了未加索引的 UPDATE/DELETE WHERE，导致锁住整张表或大量无关行
- 避免在事务内做耗时操作（如调用外部API、复杂计算），减少持锁时间
- 业务上尽量按固定顺序访问多张表，降低死锁概率
主键/唯一键冲突（Duplicate entry）
在 INSERT 或 REPLACE 操作中，违反主键（PRIMARY KEY）或唯一索引（UNIQUE INDEX）约束，事务会直接失败。常见于并发场景下“先查后插”逻辑没加锁，或使用了自增ID但手动指定重复值。
- 用 INSERT ... ON DUPLICATE KEY UPDATE 替代“查—判—插”流程，原子性解决冲突
- 对关键判断字段加唯一索引，让数据库层兜底校验
- 避免在应用层生成业务主键后不做幂等校验就直接插入
事务过大或内存不足（Undo log / Memory limit）
大事务会产生大量 undo log，占用 buffer pool 和磁盘空间。若超出 innodb_log_file_size 或系统内存限制，可能触发 ERROR 1206: The total number of locks exceeds the lock table size 或直接被OOM Killer终止。
- 单个事务修改行数建议控制在万级以内，超量操作拆分为分批提交
- 确认 innodb_undo_tablespaces 和 innodb_max_undo_log_size 配置是否合理（MySQL 8.0+）
- 避免在事务中 SELECT 大量数据并加载到应用内存，造成连接线程长时间占用
隐式提交与自动提交干扰（Autocommit / DDL）
MySQL 中某些语句会触发隐式提交（implicit commit），导致当前事务意外结束。典型包括：DDL语句（CREATE、ALTER、DROP）、LOCK TABLES、SET AUTOCOMMIT=1 等。此时再执行 COMMIT 或 ROLLBACK 会报错 ERROR 1305: SAVEPOINT does not exist 或提示“no transaction in progress”。
- 在事务块中禁止混用 DDL 操作；如需变更结构，应单独执行并确保前后无未提交事务
- 检查客户端连接是否被框架（如Spring JDBC、MyBatis）或中间件重置了 autocommit 状态
- 用 SELECT @@autocommit; 实时确认当前会话自动提交状态
