事务显著影响MySQL性能，核心在于锁管理、redo/undo日志写入、一致性校验及提交回滚开销；长事务、大事务、事务内非DB操作和不必要显式事务最伤性能；应通过读写分离、分批提交、调低隔离级别和监控拦截来平衡一致性与性能。
事务会显著影响 MySQL 的性能，核心在于它引入了额外的开销：锁管理、日志写入（redo log、undo log）、一致性校验和提交/回滚逻辑。合理使用事务能保障数据正确性，但滥用或设计不当会拖慢查询、增加锁冲突、消耗更多 I/O 和内存。
事务带来的主要性能开销
MySQL 执行一个事务，不只是执行 SQL 语句本身，还要完成一系列配套动作：
- Redo log 写入：每次事务修改数据前，必须先将变更记录写入 redo log（即使还没刷盘），这是为了崩溃恢复。频繁小事务会导致大量随机小写，加重磁盘 I/O 压力。
- Undo log 维护：为支持 MVCC 和回滚，事务运行中要持续生成 undo 日志。长事务会阻止 purge 线程清理旧版本，导致 undo 表空间膨胀、历史版本链变长，影响 SELECT 性能。
- 行锁/间隙锁争用：事务中涉及 UPDATE/DELETE/SELECT ... FOR UPDATE 时，InnoDB 会加锁。并发事务访问相同数据范围，容易触发锁等待甚至死锁，造成响应延迟或超时。
- 事务状态管理开销：每个活跃事务需维护 trx 结构体、活跃事务列表（trx_list）、read view 等，高并发下这些内存结构和全局锁（如 lock_sys->mutex）可能成为瓶颈。
哪些事务行为最伤性能
不是事务本身有问题，而是某些使用方式放大了代价：
- 长事务（Long-running transaction）：执行时间长达数秒甚至分钟。它会持有锁不放、阻塞其他事务，同时让 MVCC 版本链无法回收，极大拖慢只读查询。
- 大事务（Big transaction）：一次性修改几十万行。会产生海量 undo/redo 日志，写日志、刷盘、回滚段扩展都耗时；还可能触发自动提交失败或锁升级（虽 InnoDB 不升级锁，但锁数量剧增）。
- 在事务中做非数据库操作：比如调用外部 HTTP 接口、文件读写、复杂计算等。这会让事务空占锁和资源，人为拉长事务生命周期。
- 不必要的显式事务：对单条 SELECT 或只读场景加 BEGIN/COMMIT，虽无写操作，但仍会创建 read view、参与事务链表，徒增轻量开销。
如何平衡一致性与性能
关键是在保证业务逻辑正确的前提下，最小化事务影响范围：
- 读写分离事务边界：把 SELECT 拆出来，放在事务外执行；只在真正需要原子更新的地方开启事务（如“扣库存+生成订单”必须包在一起）。
- 批量操作分批次提交：处理 10 万行更新时，不要一口吞，按 1000~5000 行一批，每批独立事务。既控制锁持有时间，又避免单次日志过大。
- 设置合适隔离级别：多数业务用 READ COMMITTED 足够，比默认的 REPEATABLE READ 减少 gap lock 使用，降低死锁概率；仅强一致性场景才启用 SERIALIZABLE。
- 监控并拦截异常事务：通过 information_schema.INNODB_TRX 查看 trx_state、trx_started、trx_rows_locked；配合 pt-kill 或自定义脚本 kill 运行超 30 秒的事务。
附：快速判断事务是否成瓶颈的方法
登录 MySQL 后运行这几条命令，能快速定位问题：
- SHOW ENGINE INNODB STATUS\G → 关注 TRANSACTIONS 部分，看是否有大量 “lock wait” 或长时间未提交事务。
- SELECT * FROM information_schema.INNODB_TRX ORDER BY trx_started LIMIT 10; → 查出最早开始的 10 个事务，重点关注 trx_state='RUNNING' 但 trx_started 很早的。
- SHOW GLOBAL STATUS LIKE 'Com_commit'; SHOW GLOBAL STATUS LIKE 'Com_rollback'; → 对比提交/回滚比例，若 rollback 过高，说明业务逻辑或异常处理有问题。
- 检查 Innodb_row_lock_waits 和 Innodb_row_lock_time_avg → 这两个值持续升高，代表锁竞争已影响性能。
