innodb_rollback_segments默认128足够多数场景，调大仅在purge滞后（history list length与trx id差值>100万）时有效；该参数只读，须重启生效，且8.0与5.7管理机制不同，盲目调整反而加剧锁争用或拖慢purge。
innodb_rollback_segments 设置多少才够用？
它不决定“最多能开几个长事务”，而是控制回滚段（rollback segment）的并发分配能力。默认值 128 在多数场景下绰绰有余，但遇到高并发短事务 + 频繁大更新时，可能因争抢 trx_rseg_t 结构体锁而卡住提交。
- 每个活跃事务至少占用 1 个 slot（不是 1 个完整段），
innodb_rollback_segments实际是回滚段数组长度，上限 128 - 值设太高（比如 128）不会提升性能，反而增加内存开销和初始化延迟；设太低（如 8）在 OLTP 尖峰期容易触发
Waiting for purge to start或Lock wait timeout exceeded - 观察关键指标：
SHOW ENGINE INNODB STATUS中的history list Length和Trx id counter差值持续 > 100 万，说明 purge 跟不上，此时调大才有意义
为什么改了 innodb_rollback_segments 却没生效？
这个参数是只读的（read-only），mysql 启动时加载后就固定了，运行时无法动态修改 —— 试图执行 SET GLOBAL innodb_rollback_segments = 64 会直接报错 Variable 'innodb_rollback_segments' is a read only variable。
- 必须写进配置文件（如
/etc/my.cnf的[mysqld]段），然后重启 mysqld 进程 - docker 环境要注意：镜像启动时若用
--innodb-rollback-segments=64命令行参数，需确认基础镜像版本 ≥ 5.7.20，否则会被忽略 - 改完别忘了验证：
select @@innodb_rollback_segments;，而不是只看配置文件
长事务卡住，是不是该调大 innodb_rollback_segments？
大概率不是。真正拖慢长事务的是 undo log 膨胀、purge 线程滞后或 MVCC 可见性判断变慢，跟回滚段数量关系很弱。
- 典型症状：
SELECT * FROM information_schema.INNODB_TRX里看到trx_started很老，但trx_state = RUNNING，且trx_weight极高 → 问题在 undo 太大，不是段不够 - 优先检查：
innodb_purge_threads是否为 0（5.6 默认是 0，会导致 purge 单线程瓶颈）、innodb_max_purge_lag是否误设过小 - 盲目调大
innodb_rollback_segments可能让 purge 更慢：因为每个 purge 线程要轮询所有段，段越多，扫描开销越大
MySQL 5.7 和 8.0 在回滚段管理上有什么关键差异？
8.0 把回滚段彻底从系统表空间剥离到独立的 undo_001、undo_002 文件中，而 5.7 仍全放在 ibdata1 里 —— 这直接影响你能不能在线收缩 undo 空间，也改变了调参逻辑。
- 5.7：回滚段数量硬编码上限 128，且不可缩减；
innodb_rollback_segments只控制初始化时启用几个，未启用的段不占空间但会预留 slot - 8.0：引入
innodb_undo_tablespaces和innodb_undo_log_truncate，回滚段按需分配；此时innodb_rollback_segments更像是“每个 undo 表空间内最多用几个段”，默认仍是 128，但实际使用更弹性 - 升级到 8.0 后如果还沿用 5.7 的调优习惯（比如把值压到 32），反而可能让多个 undo 表空间竞争同一组段，引发新的锁争用
回滚段数量从来不是长事务的“扩容开关”，它是事务生命周期里一个极细粒度的资源调度开关——调得不对，既救不了慢查询，又可能悄悄拖垮 purge。真正要盯的，是 history list length、purge lag 和 undo 文件增长速度。