数据库连接中断不会自动回滚事务，需应用层显式处理或依赖服务端超时机制；MySQL、PostgreSQL、Oracle等均需配置相应参数并监控长事务，应用必须通过异常捕获、finally回滚、幂等设计等保障一致性。
数据库连接中断时，事务不会自动回滚，必须由应用层显式处理或依赖数据库的连接超时与会话清理机制。关键在于：连接断开本身不触发回滚，真正决定是否回滚的是事务是否已提交、连接关闭方式，以及数据库服务端是否检测到异常终止。
连接中断 ≠ 事务自动回滚
当网络闪断、客户端崩溃或主动 close() 连接时，数据库服务器通常不会立刻感知连接丢失。事务状态保持“活跃”直到超时（如 wait_timeout、interactive_timeout）或服务端心跳检测失败。此时若事务未 commit 或 rollback，可能长期占用锁、阻塞其他操作，甚至造成数据不一致。
- MySQL 默认 wait_timeout 是 28800 秒（8 小时），长时间空闲事务可能持续挂起
- PostgreSQL 使用 idle_in_transaction_session_timeout 控制空闲事务会话存活时间
- Oracle 中，死连接需依赖 SQL*Net 的死连接检测（sqlnet.expire_time）或应用层心跳
应用层必须主动管理事务生命周期
不能依赖“断连即回滚”的假设。应在代码中确保每个事务有明确的结束路径：
- 使用 try-catch-finally 或 context manager（如 Python 的 with conn.cursor()）包裹事务逻辑
- 在 finally 块中显式调用 conn.rollback()（若事务未提交且连接仍有效）
- 捕获 ConnectionError、OperationalError 等底层异常后，记录日志并触发补偿逻辑（如幂等重试或人工介入）
- 避免在事务中执行耗时操作（如 HTTP 请求、文件读写），防止连接空闲超时
启用服务端防护机制
借助数据库自身能力降低风险：
- MySQL：设置 innodb_rollback_on_timeout=ON（仅对锁等待超时生效，不覆盖网络中断）
- PostgreSQL：开启 idle_in_transaction_session_timeout = 60000（单位毫秒），强制终结卡住的事务会话
- SQL Server：配置 REMOTE QUERY TIMEOUT 和使用 SET XACT_ABORT ON，使运行时错误自动回滚当前事务
- 所有数据库：定期监控 INFORMATION_SCHEMA.INNODB_TRX（MySQL）、pg_stat_activity（PG）等视图，识别长事务并告警
设计具备容错能力的业务逻辑
面向真实故障场景，事务不是唯一防线：
- 关键操作前先查状态（例如“订单是否已支付”），避免重复执行
- 对外部系统调用采用异步+确认机制（如本地写入待发消息表，由后台任务推送并轮询结果）
- 为事务性操作添加唯一业务键（如 order_id + status），利用数据库唯一约束防重
- 日志中记录事务 ID、开始时间、涉及主键、预期变更，便于断点续传或人工修复
