事务非万能，滥用会拖慢 MySQL 性能、加剧锁冲突、增加资源消耗；需避免长事务、耗时操作、大事务批量更新，合理设置隔离级别与超时机制，并明确事务必要性。
事务不是万能的，滥用反而拖慢 MySQL 性能、增加锁冲突、消耗更多资源。核心问题在于：事务的本质是保证 ACID，而实现一致性与持久性需要额外开销——尤其是锁、日志写入和回滚段管理。
事务会显著放大锁竞争
一个 UPDATE 或 DELETE 语句加行锁，本身影响有限；但包在长事务里，锁可能持续几秒甚至更久。其他会话想改同一行，就得等——不是“慢一点”，而是直接阻塞或超时失败。
- 避免在事务里做耗时操作（如调外部 API、处理大数组、生成报表）
- 读多写少场景下，用 READ COMMITTED 隔离级别比默认的 REPEATABLE READ 更轻量，减少间隙锁范围
- 批量更新尽量拆成小事务（比如每次 500 行），而不是一口气 update 10 万行
Redo/Undo 日志压力随事务增长非线性上升
每个事务提交前，MySQL 必须把 redo 日志刷到磁盘（受 innodb_flush_log_at_trx_commit 控制）；大事务还会大量写 undo 日志，用于回滚和 MVCC。日志写入变慢，整个写入吞吐就卡住。
- 不设超长事务（例如超过 60 秒），监控 information_schema.INNODB_TRX 表及时发现
- 避免在事务中执行 SELECT … FOR UPDATE 拿锁后长时间空转
- 大表 DDL（如加索引）不要放在业务事务里，应单独低峰期执行
事务边界模糊导致隐式性能陷阱
ORM 框架（如 Laravel、Django）常默认开启事务，或自动包裹 service 方法；开发者没意识到某次“只读查询”其实被套进了事务，结果本该并发的请求被串行化，还占着连接和锁。
- 明确区分“需要事务”和“只读查询”，用 SELECT … LOCK IN SHARE MODE 或 FOR UPDATE 前先确认必要性
- 用 START TRANSACTION READ ONLY 替代普通事务做纯读操作，减少 undo 日志开销
- 检查框架配置，关闭不必要的自动事务包装（如 Spring 的 @Transactional 默认传播行为）
高并发下事务放大系统雪崩风险
一个慢事务拖住连接池，后续请求排队；若同时触发大量锁等待，可能引发连锁超时、连接耗尽、主从延迟飙升，甚至误判为数据库宕机。
- 设置合理的 wait_timeout 和 innodb_lock_wait_timeout，避免无限等待
- 关键接口加入事务执行耗时监控（如 P99 > 200ms 就告警）
- 用 pt-kill 或 sys.innodb_lock_waits 视图主动 kill 异常长事务
事务是保障数据正确的利器，不是兜底 工具。设计阶段就要想清楚：这笔操作是否真需要原子性？有没有更轻量的替代方案（如应用层幂等 + 最终一致性）？不复杂但容易忽略。
