SQL长事务是数据库稳定性的隐性威胁，会持续加剧锁冲突、Undo日志膨胀、主从延迟、资源耗尽等多维度风险，最终引发连锁故障。
SQL长事务不是“慢一点而已”，而是数据库稳定性的隐性威胁。它不一定会立刻报错，但会在锁、日志、内存、复制等多个层面持续施压，最终引发连锁反应。
锁资源长期占用，导致并发阻塞
事务一旦开始修改数据（如red">UPDATE、DELETE），InnoDB就会加行锁或间隙锁；只要没提交或回滚，锁就一直挂着。
- 其他事务想改同一行？得排队等——写阻塞写
- 在REPEATABLE READ下做SELECT ... FOR UPDATE？也可能被阻塞——写阻塞读
- 若长事务期间有人执行ALTER TABLE，还会卡住MDL元数据锁，让整张表的DDL操作动弹不得
Undo Log膨胀，拖慢MVCC与磁盘空间
Undo日志用于回滚和快照读。长事务存在时，系统不敢清理它依赖的历史版本。
- undo表空间持续增长，可能占满磁盘
- purge线程忙于维护旧版本，影响新事务的DML性能
- 其他事务查数据时，要遍历更长的版本链，CPU和IO开销明显上升
主从复制延迟加剧，影响读写分离可靠性
binlog只有在事务提交后才写入并同步到从库。长事务等于“堵住日志管道”：
- 主库binlog缓存被占满，其他小事务的日志无法及时刷出
- 从库只能串行重放，一个10分钟的事务会让从库落后至少10分钟
- 读写分离场景下，用户可能读到过期数据，业务逻辑出错
系统资源耗尽风险升高
每个活跃事务都消耗连接、内存、缓冲区等资源，长事务把这些消耗拉长、放大：
- 连接池被占满，新请求连不上数据库
- Buffer Pool被低效版本数据污染，正常查询被迫走磁盘
- 崩溃恢复时间变长——未提交事务越多、redo/undo日志越大，重启越慢
- 极端情况下触发OOM，数据库进程被系统杀掉
