事务回滚是数据库通过undo log等日志机制撤销未提交修改、保障一致性的核心手段，涵盖约束冲突、异常、显式rollback等触发场景，并需应用层主动捕获异常、调用rollback、避免长事务。
事务回滚是数据库保证数据一致性的核心机制：当事务执行过程中发生错误（如约束冲突、超时、手动触发 ROLLBACK），数据库会自动或主动撤销该事务中所有已执行的修改，使数据库状态恢复到事务开始前的一致点。
事务失败的常见触发场景
以下情况会导致事务无法正常提交，从而需要回滚：
- 违反完整性约束（如插入重复主键、外键不存在、NOT NULL 字段为空）
- 运行时异常（如除零、类型转换失败、存储过程内部报错）
- 显式执行 ROLLBACK 语句（手动中止）
- 客户端连接异常断开（多数数据库默认自动回滚未提交事务）
- 锁等待超时（如 Lock wait timeout exceeded）
回滚的实际执行过程
数据库并非简单“撤回 SQL”，而是依赖事务日志（如 MySQL 的 undo log、PostgreSQL 的 WAL 中的回滚段）进行逻辑逆操作：
- INSERT 的回滚 = 删除对应行（从 undo log 中读取原始 row_id 或主键）
- UPDATE 的回滚 = 用 undo log 中的旧值覆盖当前值
- DELETE 的回滚 = 将标记为“逻辑删除”的行重新激活（不涉及磁盘重写，仅改状态位）
- 所有回滚操作本身也受事务保护，确保回滚过程不会产生中间不一致状态
应用层如何正确处理事务失败
单纯依赖自动回滚不够，业务代码需主动识别并响应失败：
- 捕获数据库异常（如 SQLException、psycopg2.IntegrityError），区分可重试错误（超时、死锁）与不可修复错误（主键冲突）
- 在 try-catch/finally 块中确保调用 connection.rollback()（尤其连接复用场景下，避免残留未提交事务影响后续操作）
- 对幂等性要求高的场景（如支付），在事务外记录操作状态，失败后通过状态机判断是否重试或告警，而非盲目重放
- 避免在事务内做耗时操作（如 HTTP 调用、文件读写），防止长事务拖慢回滚效率和锁持有时间
调试与监控建议
定位回滚根因需结合多维度信息：
- 开启慢查询日志 + general_log（MySQL）或 pg_stat_activity（PostgreSQL），确认事务是否被长时间阻塞
- 检查 innodb_status（MySQL）或 pg_locks 视图，识别锁竞争源头
- 应用日志中记录事务开始/结束时间、SQL 摘要、错误码，便于关联分析
- 监控 Com_rollback / aborted_clients 等指标突增，及时预警异常回滚率
