避免长事务是保障MySQL高并发性能与稳定性的关键，需缩短事务生命周期、减少操作、拆分逻辑、合理设隔离级别及超时，并加强监控预警。
避免长事务是 MySQL 高并发场景下保障性能与稳定性的关键。长事务会持续占用锁资源、阻塞其他事务、拖慢 MVCC 清理，甚至引发主从延迟或 OOM。核心思路是：缩短事务生命周期、减少事务内操作、拆分逻辑、合理使用隔离级别。
控制事务边界，显式及时提交
很多长事务源于事务开启后未主动结束，比如在应用层开启事务但忘记 commit/rollback，或在循环中误将整个批量操作包在一个事务里。
- 用 BEGIN / START TRANSACTION 明确开启，COMMIT / ROLLBACK 显式收尾，避免依赖自动提交（autocommit=0）的隐式行为
- 批量写入时，按固定大小（如 100~500 行）分批提交，而不是“一口气插完再提交”
- 业务逻辑中避免在事务内做 RPC 调用、文件读写、睡眠等耗时操作——这些会让事务空挂，锁却一直不放
精简事务内 SQL，减少锁持有时间
事务越长，加锁时间越久，冲突概率越高。尤其 UPDATE/DELETE 涉及非唯一索引或范围扫描时，可能升级为间隙锁或临键锁，影响更大。
- 只在事务中放真正需要原子性保证的语句；日志记录、缓存更新、通知推送等可移出事务
- UPDATE 前先用 SELECT ... FOR UPDATE 加锁？不一定必要——若能通过唯一键精准定位且无并发覆盖风险，可改用带条件的 UPDATE（如 UPDATE t SET x=1 WHERE id=123 AND version=5），避免额外查询和锁竞争
- 避免在事务中执行 SELECT * FROM huge_table WHERE ... 这类全表扫描，容易导致 undo log 膨胀和锁等待
合理设置事务隔离级别与超时机制
默认的 REPEATABLE READ 虽然一致性好，但在高并发更新场景下更容易因间隙锁引发死锁或锁等待。适当降级 + 主动防御更实用。
- 读多写少且允许幻读的场景，可考虑 READ COMMITTED：它不使用间隙锁（除外键检查和唯一约束冲突外），大幅降低锁冲突
- 在应用层或 MySQL 层配置 innodb_lock_wait_timeout（默认 50 秒），配合业务重试逻辑，避免一个慢事务拖垮整条链路
- 对关键事务加 SET innodb_lock_wait_timeout = 3 等短超时，失败快、反馈快、恢复快
监控与识别长事务，建立预警机制
靠经验防不住所有问题，必须用数据说话。MySQL 提供了直接可观测的入口。
- 查活跃长事务：SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW()) - TIME_TO_SEC(TRX_STARTED) > 60;
- 关联锁信息：SELECT * FROM information_schema.INNODB_LOCK_WAITS; 和 INNODB_LOCKS（8.0+ 已废弃，改用 performance_schema.data_locks）
- 开启 long_query_time = 0 并记录所有事务起止到慢日志，结合 pt-query-digest 分析事务模式
- 在监控系统（如 Prometheus + Grafana）中埋点 trx_started、trx_state、trx_rows_modified，对运行超 5 秒的事务打标告警
