redo log 和 undo log 配置需匹配负载与硬件，非越大越好；mysql 8.0+ 推荐单个 redo 日志设 1g～2g、保持默认 2 个文件，停库前须执行 set global innodb_fast_shutdown = 0，并通过 show engine innodb status 监控 checkpoint age；innodb_flush_log_at_trx_commit=1 保障强持久性，ssd 可压测后选 2；undo 应启用独立表空间与自动截断，严控长事务；buffer pool 至少占物理内存 70%，协同优化才有效。
Redo Log 和 Undo Log 不是“调高就快”的配置项，盲目增大反而会拖慢吞吐——关键在匹配负载模式与硬件特性。
Redo Log 文件大小和数量怎么设？
默认的 innodb_log_file_size=48M 和 innodb_log_files_in_group=2 适合小流量场景，但写密集业务下极易触发频繁 checkpoint，导致刷脏页阻塞。
- 单个文件大小建议设为
1G～2G（MySQL 8.0+ 支持在线调整），目标是让 checkpoint 间隔 ≥ 30 分钟，可通过SHOW ENGINE INNODB STATUS查看Log sequence number和Last checkpoint at的差值估算 - 文件数量保持默认
2即可，增加到4并不能线性提升并发写入能力，反而增加 recovery 时间 - 修改前必须停库，且需先
SET GLOBAL innodb_fast_shutdown = 0，否则旧日志可能被截断导致数据丢失
Redo Log 刷盘策略对吞吐影响有多大？
innodb_flush_log_at_trx_commit 是最敏感的参数，它直接决定事务提交时 redo log 是否落盘：
-
1：每次 commit 都fsync到磁盘 → 强持久性，但随机 I/O 压力大，吞吐受限于磁盘延迟 -
0：每秒刷一次 + 事务只写 buffer → 吞吐最高，但宕机最多丢 1 秒数据 -
2：commit 时写 OS cache，不fsync→ 折中方案，依赖 OS 稳定性，SSD 上通常够用
线上 OLTP 业务推荐设为 1；若用 NVMe SSD 且能接受极小概率数据丢失，可压测后选 2。
Undo Log 大小和清理机制怎么避免拖慢查询？
Undo Log 不是越大越好，长事务会让版本链无限增长，MVCC 查询要遍历整条链，SELECT 变慢、purge 线程跟不上就会撑爆 ibdata1。
- 启用独立表空间：
innodb_undo_tablespaces = 32（MySQL 5.7+），避免 undo 段挤占系统表空间 - 开启自动回收：
innodb_undo_log_truncate = ON，配合innodb_max_undo_log_size = 1G，让 purge 线程定期截断闲置 undo 段 - 严格监控长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 60，超过 60 秒必须告警干预
Buffer Pool 与 Redo/Undo 的协同要点
Redo 和 Undo 的效率高度依赖 Buffer Pool 行为：
-
innodb_buffer_pool_size至少设为物理内存的 70%，否则大量页 IO 会淹没 redo 写入带宽 -
innodb_flush_neighbors = 0（SSD 必开），避免刷脏页时连带刷无关页，减少无谓 I/O - 不要把
innodb_log_buffer_size设得过大（默认16M足够），它只缓存未提交事务的日志，不是越大越快
真正卡吞吐的，往往不是日志本身容量，而是 checkpoint 频率、purge 延迟、或 Buffer Pool 争用——这些点比单纯调大 innodb_log_file_size 更值得优先排查。
