MySQL 8.0+ 已完全移除 innodb_rollback_segments，设为只读默认值128且不可修改；实际回滚段由InnoDB动态管理，调优应聚焦 innodb_undo_tablespaces、innodb_max_undo_log_size 和事务管控。
MySQL 8.0+ 已移除 innodb_rollback_segments，改用动态回滚段管理，硬调这个参数无效。
为什么 SET innodb_rollback_segments 不起作用
从 MySQL 5.7.20 开始，innodb_rollback_segments 被标记为 deprecated；到 MySQL 8.0 完全移除。你执行 SET GLOBAL innodb_rollback_segments = 128 不会报错，但实际不会生效——InnoDB 启动后会自动根据并发负载和 undo 表空间数量动态分配活跃回滚段（通常为 128 个），且不可手动覆盖。
- 查当前实际生效值：
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'innodb_rollback_segments';—— 返回的仍是只读默认值（如 128），不代表运行时控制权在你手上 - 该参数在配置文件中写入也仅作兼容占位，启动日志里会出现警告：
[Warning] InnoDB: innodb_rollback_segments is ignored - 真正影响回滚能力的是
innodb_undo_tablespaces和innodb_max_undo_log_size，不是这个“假开关”
长事务报错（如 Lock wait timeout、ORA-01555 类似现象）该调什么
回滚失败或快照过期，根本原因不是“回滚段数量少”，而是 undo 空间被提前回收、或单事务生成 undo 过大导致空间争抢。需盯住三个真实可控参数：
-
innodb_undo_tablespaces：设为 ≥2（推荐 4～8），让 undo 日志分散到多个独立表空间（undo_001、undo_002…），避免单个文件膨胀阻塞 purge；注意它必须在初始化实例时设置，运行中无法增删 -
innodb_max_undo_log_size：默认 1GB，控制每个 undo 表空间内可增长上限；设太高易占满磁盘，太低会导致频繁 truncate undo log，引发回滚失败或快照丢失；线上建议 512MB～2GB，配合监控information_schema.INNODB_METRICS中undo_truncations计数调整 -
innodb_purge_rseg_truncate_frequency：默认 128，表示 purge 线程每做 128 次 purge 操作才尝试截断一次 undo log；值越小，truncate 越激进，越容易丢快照；高并发 OLTP 建议调大到 512 或 1024，减少误截断
如何验证 undo 空间是否真成瓶颈
别猜，直接查指标。以下 SQL 必须定期跑：
- 看当前 undo 占用：
SELECT SUM(curr_size) * 16384 / 1024 / 1024 AS undo_mb FROM information_schema.INNODB_TABLESPACES WHERE NAME LIKE 'undo%'; - 看 purge 压力：
SELECT COUNT(*) FROM information_schema.INNODB_TRX WHERE TRX_STATE = 'RUNNING' AND TIME_TO_SEC(NOW() - TRX_STARTED) > 60;—— 超 60 秒的活跃事务越多，purge 越难跟上 - 看是否频繁截断：
SELECT * FROM information_schema.INNODB_METRICS WHERE NAME = 'undo_truncations';—— 如果每分钟增长 >5，说明innodb_max_undo_log_size很可能设小了
如果 undo_truncations 高 + curr_size 接近 innodb_max_undo_log_size，就是空间不够用，而不是“回滚段太少”。
真正该做的：用事务控制代替参数硬调
所有靠调大 undo 相关参数来“扛”长事务的做法，都是在掩盖业务问题。MySQL 的 undo 设计本就不适合支撑小时级事务。你应该：
- 在应用层强制事务超时：ORM 中设
timeout=30，或连接串加sessionVariables=innodb_lock_wait_timeout=10 - 拆分大更新：用
WHERE id BETWEEN ? AND ? LIMIT 1000分批，每批单独COMMIT - 禁用事务内非 DB 操作：HTTP 调用、日志写入、文件处理一律移到
COMMIT后 - 监控并自动 kill 真正的长事务：
KILL QUERY <code>trx_mysql_thread_id（不是 KILL CONNECTION），脚本化执行，别等它拖垮 purge 线程
回滚段数量是 InnoDB 内部调度细节，不是调优接口。把精力放在事务生命周期管理和 undo 空间水位监控上，比折腾一个已废弃的参数实在得多。
