为什么 SQL 中要避免使用长事务？
长事务（Long-Running Transaction）指执行时间很长（从几秒到几小时）或持有锁资源过久的事务。它会带来一系列严重问题，具体如下：
1. 长时间持有锁，阻塞其他事务
- 事务在提交或回滚前，会一直持有其获取的锁（行锁、间隙锁、表锁等）。
- 其他事务若需要访问被锁定的数据，就必须等待，导致响应延迟 甚至系统雪崩。
- 例如：一个长事务更新了某张表的百万行数据，未提交；此时其他会话尝试更新同一行，就会被阻塞。
2. 增加死锁风险
- 长事务持有大量资源的锁，其他事务也在等待并持有另一些锁，容易形成循环依赖，触发死锁。
- 死锁后数据库虽然会自动回滚其中一个事务，但长事务被回滚的代价极高（见第 4 点）。
3. 事务日志膨胀，磁盘压力大
- 数据库必须保留事务日志（如 MySQL 的 undo log / redo log，PostgreSQL 的 WAL）用于回滚或 MVCC（多版本并发控制）。
- 长事务持续修改数据，日志不断累积，直到事务结束才能清理，可能撑满磁盘，导致数据库崩溃。
- 例如：在可重复读隔离级别下，长事务会让 undo 日志无法被 purge，导致表空间膨胀。
4. 回滚代价极高
- 如果长事务执行中出错或被手动回滚，数据库必须撤销所有已执行的操作。
- 回滚时间与事务执行时间成正比，可能花费几十分钟甚至几小时，期间还会持有锁。
- 例如：一个运行了 2 小时的批量更新事务，回滚可能也需要 2 小时，系统几乎不可用。
5. 严重影响并发性能
- 数据库连接池中，长事务会长时间占用一个连接，导致连接耗尽，其他请求无法获取连接。
- 在高并发场景下，长事务会成为"性能热点"，拖垮整个应用。
6. 导致主从复制延迟
- 在主从架构中，长事务在主库提交后，从库需要重放其全部更改。
- 如果事务很大且持续时间长，从库的 SQL 线程或应用进程可能卡住，造成主从延迟增大，影响读一致性。
7. MVCC 版本链过长，查询变慢
- 在 MySQL（InnoDB）、PostgreSQL 等使用 MVCC 的数据库中，长事务会保留其开始时刻的快照。
- 为避免幻读，数据库必须保留该快照后的所有历史版本，导致后续查询需要遍历很长的版本链（尤其是
SELECT ... FOR UPDATE），性能下降。
典型案例
sql
-- 反例：在业务代码中开启事务后，还调用外部 API 或执行慢操作
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- 调用第三方支付接口（可能耗时 10 秒）
-- 或者执行复杂的循环计算
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;问题：事务中包含了非数据库操作，导致锁持有 10 秒以上，阻塞所有对账户 1 和 2 的并发操作。
如何避免长事务？
- 拆分大事务：将批量操作拆成多个小事务，例如每 1000 行提交一次。
- 不在事务中混入外部调用：如 RPC、HTTP、文件 I/O 等。
- 设置超时参数 ：
innodb_lock_wait_timeout、transaction_timeout等，自动回滚过长事务。 - 监控并告警 ：定期查询
information_schema.innodb_trx，杀掉运行过久的事务。 - 合理选择隔离级别 ：如果业务允许，使用
READ COMMITTED减少间隙锁和 MVCC 版本保留。 - 代码层面 ：确保
try-catch中无论成功还是异常都及时COMMIT或ROLLBACK。
总结
| 问题 | 后果 |
|---|---|
| 锁持有过久 | 阻塞并发，响应变慢 |
| 日志膨胀 | 磁盘爆满，服务宕机 |
| 回滚困难 | 故障恢复时间长 |
| 连接占用 | 连接池枯竭 |
| 主从延迟 | 读不一致 |
最佳实践：让事务尽可能短、快、小------仅将真正需要原子性的数据库操作放在事务内，完成后立即提交。