MySQL事务提交失败时，核心是定位原因、回滚操作、修复问题后重试，而不是强行提交。
检查事务失败的具体错误信息
MySQL报错日志或客户端返回的错误码（如1205死锁、1213锁等待超时、1062主键冲突等）直接决定处理方式。执行SHOW ENGINE INNODB STATUS\G可查看最近的死锁详情；应用层需捕获异常并记录完整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） 对关键业务添加幂等性设计（如用唯一业务单号防止重复提交）不复杂但容易忽略的是：事务失败后别只盯着“怎么提交”，先确认“为什么失败”——多数问题出在逻辑设计或并发控制，而非语法或配置。
