事务提交失败主因是前置DML报错、事务状态异常或配置问题；需检查autocommit模式、in_transaction状态、错误码（如1062/1452/1213）、锁等待及存储引擎是否均为InnoDB。
事务提交
COMMIT 本身极少直接报错（它不校验逻辑），真正失败通常发生在 INSERT/UPDATE/DELETE 执行阶段或隐式提交前的约束检查环节。关键要区分是 SQL 执行异常、事务状态异常，还是连接/配置问题。
检查事务是否已处于非活动状态
MySQL 要求事务必须“开启且未结束”才能提交。常见误操作包括：
- 执行了
COMMIT或ROLLBACK后再次调用COMMIT—— 此时会报ERROR 1373 (HY000): Cannot modify an existing transaction或类似提示（取决于版本）； - 事务因超时自动回滚（
wait_timeout或interactive_timeout触发），后续COMMIT实际无事务可提交； - 使用了
AUTOCOMMIT=1模式，每条语句独立提交，显式BEGIN后未出错却忘记COMMIT，导致误以为“提交失败”。
建议：执行 SELECT @@autocommit; 确认模式；用 SELECT @@in_transaction; 判断当前是否在事务中；用 SHOW ENGINE INNODB STATUS\G 查看最近事务状态。
捕获并解析具体 SQL 错误码和消息
绝大多数“提交失败”本质是前置 DML 报错未被处理，导致事务无法继续。例如：
- 唯一键冲突（
ERROR 1062 (23000)）； - 外键约束失败（
ERROR 1452 (23000)）； - 数据类型不匹配或超出长度（
ERROR 1265 (01000)）； - 死锁被选为牺牲者（
ERROR 1213 (40001)）。
务必在应用层捕获完整错误信息，不要只看“提交失败”字面。使用 GET DIAGNOSTICS（MySQL 5.6+）或客户端的 mysql_error()/mysqli_error() 获取准确错误号与文本。对死锁类错误，应重试事务而非直接报错。
确认隔离级别与锁行为是否引发隐式阻塞
在 REPEATABLE READ 或 SERIALIZABLE 下，某些查询（如 SELECT ... FOR UPDATE）会加锁，若持有锁时间过长或出现循环等待，可能导致后续 COMMIT 卡住或超时。表现常为连接长时间无响应，而非立即报错。
排查方法：
- 执行
SELECT * FROM information_schema.INNODB_TRX;查看运行中的事务及其状态、运行时间、锁定情况； - 结合
INNODB_LOCK_WAITS和INNODB_LOCKS（MySQL 5.7 及以前）或performance_schema.data_locks（8.0+）分析锁等待链； - 检查是否有长事务未提交（
trx_started时间过早），及时优化或终止。
验证存储引擎与事务支持配置
不是所有表都支持事务。如果事务中混用了 MyISAM 表（不支持事务）和 InnoDB 表，DML 对 MyISAM 的修改会立即生效且不可回滚，而 COMMIT 仅作用于 InnoDB 部分——这容易造成“部分写入成功但整体感知失败”的错觉。
确认方式：
- 执行
SHOW CREATE TABLE table_name;查看引擎类型； - 统一使用
ENGINE=InnoDB创建表； - 避免在事务中操作非事务型引擎表，或明确将其排除在事务逻辑外。
不复杂但容易忽略
