事务提交失败时，核心是先定位错误原因，再针对性解决。MySQL 中
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创建表； 避免在事务中操作非事务型引擎表，或明确将其排除在事务逻辑外。
不复杂但容易忽略
