mysql事务提交失败时应先定位原因再回滚修复，不可强行提交；需检查错误码（如 1205 死锁、1062 主键冲突），自动回滚未提交事务，应用层捕获异常并重试，使用 InnoDB 引擎，避免不可回滚操作，加强数据校验与幂等设计。
MySQL 事务提交失败时，核心是定位原因、回滚操作、修复问题后重试，而不是强行提交。
检查事务失败的具体错误信息
mysql 报错 日志或客户端返回的错误码（如 1205 死锁、1213 锁等待超时、1062 主键冲突等）直接决定处理方式。执行 SHOW ENGINE INNODB STATUSG 可查看最近的死锁详情；应用层需捕获异常并记录完整 SQL 和错误码。
自动回滚未提交的事务
只要事务尚未显式执行COMMIT，MySQL 在连接断开、客户端异常退出或遇到不可恢复错误时会自动回滚。开发中应确保：
- 所有 START TRANSACTION 都有对应 COMMIT 或ROLLBACK逻辑
- 使用支持事务的存储引擎（如 InnoDB），MyISAM 不支持事务
- 避免在事务中调用无法回滚的操作（如 DROP table、CREATE TABLE、发送http 请求等）
常见异常类型与应对策略
死锁（Error 1213）：MySQL 自动回滚其中一方事务，应用需捕获该错误并重试整个业务逻辑。
唯一键冲突（Error 1062）：检查是否重复插入相同主键 / 唯一索引值，改用 INSERT … ON DUPLICATE KEY UPDATE 或先 select 再判断。
锁等待超时（Error 1205 或 Lock wait timeout exceeded）：优化 SQL 减少锁持有时间，拆分大事务，加索引避免全表扫描，必要时调整 innodb_lock_wait_timeout 参数。
数据一致性校验失败（如外键约束、CHECK 约束）：在事务开始前验证输入数据合法性，比依赖 数据库 报错更可控。
应用层事务控制建议
避免裸写 SQL 事务，优先使用框架的事务管理能力（如 spring 的@Transactional、laravel的 DB::transaction）。手动控制时务必：
- 用 try…catch 包裹事务块，异常时明确执行ROLLBACK
- 设置合理超时（如SET innodb_lock_wait_timeout = 30）
- 对关键业务添加幂等性设计（如用唯一业务单号防止重复提交）
不复杂但容易忽略的是：事务失败后别只盯着“怎么提交”，先确认“为什么 失败”——多数问题出在逻辑设计或 并发 控制，而非语法或配置。
