生产环境MySQL 8.0必须定制redo log和undo log：redo总大小建议2～8GB（如2G×2=4GB），金融系统设innodb_flush_log_at_trx_commit=1；undo须独立存放（innodb_undo_directory=/data/mysql/undo/）、开启截断（innodb_undo_log_truncate=ON）并调大阈值至2～4G。
生产环境 MySQL 8.0 的 redo log 和 undo log 不能按默认值一跑了之——默认配置在高并发或大事务场景下极易引发日志写满、空间膨胀、恢复变慢甚至备份失败。必须结合磁盘性能、事务吞吐、RPO/RTO 要求做针对性规划。
如何设置 redo log 总大小与刷盘策略
关键不是单个文件多大，而是总容量是否匹配你的峰值写入压力。总大小 = innodb_log_file_size × innodb_log_files_in_group（默认为 2）。生产建议控制在 2GB～8GB 区间：
-
innodb_log_file_size = 2G（单文件） +innodb_log_files_in_group = 2→ 总 4GB，适合中等 OLTP 场景； - 金融类系统若要求 RPO=0，
innodb_flush_log_at_trx_commit = 1必须开启，但需确认磁盘是低延迟 SSD； - 若用 SATA 盘或云盘 IOPS 不足，设为 2 可缓解刷盘压力，但宕机可能丢失最多 1 秒事务；
- 修改
innodb_log_file_size必须停机：先SET GLOBAL innodb_fast_shutdown = 0，再关闭 mysqld，删掉ib_logfile*，改配置后重启。
为什么 undo log 必须独立存放且启用自动截断
MySQL 8.0 默认已将 undo 表空间独立化，但若仍沿用默认的 innodb_undo_directory = ./（即和数据文件同目录），会引发 I/O 竞争和空间不可控增长：
- 务必指定高性能路径：
innodb_undo_directory = /data/mysql/undo/（提前chown mysql:mysql）； -
innodb_undo_log_truncate = ON必须开启，否则大事务或长事务未提交时，undo 表空间只增不减； -
innodb_max_undo_log_size建议设为2G～4G（而非默认 1G），避免过于频繁的截断触发 purge 压力； -
innodb_purge_threads在高并发更新场景下建议调至 8～16，但不得超过 CPU 核心数的一半。
Redo Log 归档功能该不该开？什么时机开
归档不是常驻开关，而是“按需启用”的临时能力，专为备份窗口期服务。MySQL 8.0.17+ 支持，但误用反而拖慢主库：
- 仅在执行物理备份（如
xtrabackup --backup）前启动：DO innodb_redo_log_archive_start('arch_dir', 'backup_20261013');； - 归档目录必须是独立挂载点（如 NVMe 分区），且禁止与
innodb_undo_directory或数据目录共用磁盘； - 归档期间每秒会产生多个
archive_*.bin文件，需监控磁盘余量，避免撑爆； - 备份结束立即停用：
DO innodb_redo_log_archive_stop();，并手动清理归档目录（归档文件不自动删除）。
最容易被忽略的是：redo log 大小调整和 undo 目录迁移都涉及停机或重建表空间操作，这些不能等到上线后才做——必须在实例初始化阶段完成。线上扩缩容时，宁可预留冗余空间，也不要中途动日志配置。
