事务深度直接影响单机TPS，因其延长锁持有时间、加剧undo日志与回滚段压力，导致并发写入阻塞；实测显示单事务超8条跨3表UPDATE时TPS下降40%~65%。

为什么事务深度直接影响单机TPS

事务深度指一个事务中包含的SQL语句数量及其执行复杂度。深度越大，锁持有时间越长、undo日志增长越快、回滚段压力越高——这些都会直接卡住并发写入通路。实测显示：当单事务平均含8条以上UPDATE且跨3张表时，tps比拆分为多个短事务下降40%~65%，尤其在innodb_flush_log_at_trx_commit=1配置下更明显。

如何识别事务过深的实际信号

别只看代码里有没有BEGIN和COMMIT，重点查运行态表现：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• show engine innodb status 中 TRANSACTIONS 部分持续出现 lock wait timeout exceeded 或 waiting for table metadata lock
• information_schema.innodb_trx 表里 trx_started 时间戳比当前时间早数秒甚至数十秒，且 trx_state = 'RUNNING'
• 慢查询日志中大量 COMMIT 出现在 long_query_time 之上（说明提交本身耗时）
• show global status like 'innodb_row_lock_waits' 每秒增幅 > 5，伴随 innodb_row_lock_time_avg > 10000 微秒

缩短事务深度的实操策略

不是简单“加个COMMIT”，而是按数据一致性边界做切分：

• 读写分离：把事务内先SELECT再UPDATE的模式，改为用SELECT ... FOR UPDATE显式加锁，但仅锁定必要行；避免先读再算再更新的“三步曲”
• 批量操作降粒度：用 INSERT INTO ... VALUES (...), (...), (...) 替代循环单条INSERT，但单批不超过500行（防止innodb_log_file_size写满触发同步刷盘）
• 异步化非关键路径：如订单创建后发通知、更新统计值等，从主事务中剥离，改由应用层投递到消息队列或延迟任务表
• 避免在事务中调用外部服务（HTTP/API/Redis），网络超时会无限延长事务生命周期

配合参数规避事务深度放大效应

即使业务逻辑已优化，底层参数不匹配仍会放大问题：

• innodb_lock_wait_timeout 建议设为 10~30（默认50），让锁冲突快速失败而非死等
• innodb_rollback_on_timeout 必须为 ON（MySQL 8.0 默认），否则超时后事务不自动回滚，残留锁持续阻塞其他连接
• innodb_max_purge_lag 若观察到 purge lag 持续 > 10000，需调大该值并检查是否有长事务未提交（purge线程被堵）
• 禁用autocommit=0全局设置，强制应用显式控制事务边界；否则任意UPDATE都可能意外开启隐式事务

事务深度不是代码缩进问题，是锁资源调度的实时博弈。最容易被忽略的是：开发常认为“我只改一行，不会锁太久”，却没意识到这一行可能被上游事务锁了10秒——而你的事务正卡在等待它释放。监控innodb_trx和innodb_locks必须成为上线前基线检查项。