innodb_rollback_segments 控制innodb初始化时预分配并激活的回滚段个数，而非总回滚段数量；默认启用前128个中的指定数量，未启用者不参与事务分配。
innodb_rollback_segments 参数到底控制什么
innodb_rollback_segments 并不直接控制“回滚段数量”，而是控制 InnoDB 初始化时**预分配并激活的回滚段个数**。InnoDB 内部最多支持 128 个回滚段（其中 32 个专用于临时表），但默认只启用 128 个中的前 innodb_rollback_segments 个。未启用的回滚段不会参与事务分配，也就不会被使用。
高并发写入场景下，多个事务争抢同一个回滚段的 undo slot（日志槽位）会引发锁等待，表现为 ROLLBACK_SEGMENT 类型的等待事件，或在 SHOW ENGINE INNODB STATUS 中看到大量事务卡在 “inserting into rollback segment” 状态。
怎么调这个值才有效
盲目增大 innodb_rollback_segments 不一定提升性能，关键看是否真存在回滚段争用，且当前值已成瓶颈：
- 确认争用：查
Innodb_metrics表，重点关注trx_rseg_global_history_len（全局历史列表长度）持续 > 10000，或trx_rseg_n_segments接近当前配置值 - 合理范围：MySQL 5.7+ 默认是 128，但实际有效上限受
innodb_undo_tablespaces影响——每个 undo 表空间最多承载 128 个回滚段；若只用系统表空间（innodb_undo_tablespaces = 0），即使设为 128，也受限于 ibdata1 的结构布局，实测稳定值通常在 32–64 之间 - 生产建议：从 32 开始逐步调高，每次调整后观察
SHOW ENGINE INNODB STATUS中的ROLLBACK SEGMENTS小节，确认新增段被真正分配且有活跃事务使用
和 innodb_undo_tablespaces 必须配着看
innodb_rollback_segments 的效果高度依赖 undo 表空间的物理组织方式：
- 若
innodb_undo_tablespaces = 0（默认，undo 日志全写进ibdata1），回滚段共享同一文件，增大innodb_rollback_segments只能缓解逻辑争用，I/O 层仍串行；此时更应优先考虑迁出 undo 到独立表空间 - 若已启用独立 undo 表空间（如
innodb_undo_tablespaces = 4），每个表空间可承载最多 128 个回滚段，此时把innodb_rollback_segments设为 128 才可能真正分散 I/O 和锁压力 - 注意：修改
innodb_undo_tablespaces必须在实例初始化时设置，运行中修改会导致 MySQL 启动失败
容易被忽略的副作用
调大 innodb_rollback_segments 不只是“多开几个段”那么简单：
- 内存占用增加：每个回滚段需维护 header、slot 数组、链表指针等元数据，虽单个不大，但 128 个叠加后对 Buffer Pool 控制块区域有可观消耗
- Purge 线程压力上升：更多回滚段意味着更多待清理的 undo log 链，若
innodb_purge_threads未同步调高，history list 可能持续堆积 - 长事务危害放大：每个回滚段都可能被一个长事务独占，段越多，潜在被“钉住”的 undo log 总量越大，
innodb_max_undo_log_size和innodb_undo_log_truncate的配合就更关键
真正压倒性的竞争往往不在回滚段本身，而在于事务没及时提交——再好的段分布也救不了卡在应用层 30 秒不 commit 的连接。
