mysql事务提交失败是数据库开发中比较常见的异常情况，通常发生在事务执行过程中出现约束冲突、锁等待超时、连接中断或者磁盘空间不足等问题之后，此时需要按照规范的操作流程恢复数据状态，避免产生脏数据或者数据不一致的问题。
事务提交失败的常见原因
想要正确恢复事务，首先需要明确事务提交失败的常见诱因，主要有以下几类：
- 数据约束冲突：比如插入的数据违反了主键唯一约束、外键约束或者非空约束，mysql会直接拒绝提交事务。
- 锁等待超时：事务执行过程中需要获取的行锁或者表锁被其他事务长时间占用，超过了innodb_lock_wait_timeout设置的阈值，事务会提交失败。
- 连接异常中断：客户端和mysql服务端的连接在执行事务过程中断开，未完成的事务会被自动回滚，提交操作自然失败。
- 服务端异常：mysql服务崩溃、磁盘空间不足、事务日志文件损坏等情况，也会导致事务提交失败。
事务提交失败的基础恢复方法
手动回滚未完成事务
如果事务还未自动回滚，且你还在当前数据库连接会话中，可以直接执行回滚命令恢复数据到事务开始前的状态：
-- 开启事务 START TRANSACTION; -- 执行更新操作 UPDATE user SET balance = balance - 100 WHERE id = 1; -- 发现操作有误，手动回滚 ROLLBACK; -- 再次查询数据，确认恢复到操作前状态 SELECT balance FROM user WHERE id = 1;
如果事务已经因为连接中断等原因自动回滚，再次执行ROLLBACK命令不会生效，此时需要确认数据状态后再重新执行事务操作。
查看错误日志定位问题
事务提交失败时mysql会返回对应的错误码和错误信息，你可以根据这些信息判断失败原因，再针对性处理：
-- 执行事务提交，捕获错误信息 START TRANSACTION; INSERT INTO order (user_id, amount) VALUES (1, 200); -- 如果插入违反主键约束，提交会失败，查看最近一次错误 SHOW ERRORS; -- 输出示例：错误码1062，错误信息：Duplicate entry '1' for key 'PRIMARY'
如果是约束冲突问题，需要修改插入或者更新的数据，避开冲突后再重新提交；如果是锁等待超时，可以排查持有锁的其他事务，优化事务执行逻辑，缩短锁占用时间。
特殊场景的恢复处理
事务日志损坏的恢复
如果是innodb的事务日志（redo log或者undo log）损坏导致事务提交失败，需要先停止mysql服务，备份数据文件后，尝试修复日志：
# 停止mysql服务 systemctl stop mysqld # 备份原有的事务日志文件 cp /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile0.bak cp /var/lib/mysql/ib_logfile1 /var/lib/mysql/ib_logfile1.bak # 删除原有的日志文件，重启mysql会自动生成新的日志文件 rm -f /var/lib/mysql/ib_logfile0 rm -f /var/lib/mysql/ib_logfile1 # 启动mysql服务 systemctl start mysqld
注意这个操作需要在数据备份完成后进行，避免日志删除导致数据无法恢复。
长事务提交失败的处理
长事务长时间未提交，不仅容易出现提交失败，还会占用大量资源，你可以通过information_schema库查询当前运行的长事务：
-- 查询执行时间超过60秒的事务 SELECT trx_id, trx_started, trx_state, trx_query FROM information_schema.innodb_trx WHERE TIMESTAMPDIFF(SECOND, trx_started, NOW()) > 60;
如果查询到异常的长事务，且确认已经提交失败，可以直接kill掉对应的事务线程，释放占用的资源，再重新执行事务操作。
预防事务提交失败的优化建议
为了减少事务提交失败的概率，日常开发中可以采取以下优化措施：
- 尽量缩短事务的执行时间，避免在事务中执行耗时操作，减少锁占用时长。
- 合理设置锁等待超时参数，根据业务场景调整innodb_lock_wait_timeout的值，避免过短导致正常事务提交失败。
- 执行事务操作前先校验数据的合法性，比如检查主键是否存在、外键关联数据是否有效，减少约束冲突的概率。
- 定期备份数据库，同时监控mysql服务的磁盘空间、连接数等指标，提前发现潜在的异常风险。