MySQL 8.0.30+ 必须用 innodb_redo_log_capacity 替代已废弃的 innodb_log_file_size，旧版本需停库删 ib_logfile* 后调整；容量应按峰值写入×RTO 计算，避免过大导致恢复变慢；监控 Log sequence number 与 Last checkpoint 差值、刷盘延迟及 Innodb_log_waits 才能精准调优。
先确认 MySQL 版本，再决定用哪个参数
MySQL 8.0.30+ 彻底废弃 innodb_log_file_size，只认 innodb_redo_log_capacity；低于该版本才走老路。配置里混写两者会直接启动失败，报错：Unknown variable 'innodb_log_file_size'。
执行 SELECT VERSION(); 看清版本号，别凭印象改配置。8.0.30+ 的配置文件中必须删掉所有 innodb_log_file_size 和 innodb_log_files_in_group 相关行，否则 mysqld 拒绝加载。
旧版本（如 8.0.29）调整前必须停库、手动删除 ib_logfile0 和 ib_logfile1，否则启动报错：InnoDB: Error: log file ./ib_logfile0 is of different size。
算准 innodb_redo_log_capacity 值，不是越大越好
容量失衡会导致 checkpoint 过密或刷盘延迟飙升——实测写入量 × RTO（恢复时间目标）才是依据。比如峰值写入 30MB/s，要求崩溃后 5 分钟内恢复，则推荐值为 30 * 1024 * 1024 * 300 = 9663676416 字节（≈9.2GB）。
SSD 环境可压缩 20%～30%；HDD 则建议保留余量，避免 checkpoint 频繁触发。在线调整只需：SET GLOBAL innodb_redo_log_capacity = 9663676416;，无需重启。
别拍脑袋设 8GB 或 16GB：若实际日志生成量远低于该值，InnoDB 每次崩溃恢复都得扫描全部空间找有效段落，白白多花数秒甚至分钟。
- 监控差值：
SHOW ENGINE INNODB STATUS\G中看Log sequence number和Last checkpoint at的差值，持续 >70% 总容量说明太小 - 盯住刷盘延迟：
Log flushed up to和Log written up to差值长期 >100MB，说明缓冲或磁盘吞吐跟不上
大事务卡顿？先调 innodb_log_buffer_size，不是 redo 文件大小
默认 16MB 的 innodb_log_buffer_size 在批量导入、含大 BLOB 的事务中极易撑满，触发频繁 flush 和内存拷贝，表现为 Innodb_log_waits 持续上升、TPS 抖动。这不是日志文件不够大，而是内存缓冲区瓶颈。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
查当前值：SHOW VARIABLES LIKE 'innodb_log_buffer_size';。从 64MB（67108864）起步；单事务 redo 日志常超 100MB 可设到 128MB（134217728）。
注意：该参数只影响未提交事务的内存缓冲，不改变磁盘日志大小，也不放大崩溃丢失风险。别盲目冲到 512MB 以上——收益快速衰减，且会挤占 InnoDB 内存池。
innodb_flush_log_at_trx_commit 设为 2 的真实代价
设成 2 能显著缓解磁盘 I/O，但代价是主机断电或 mysqld 崩溃时最多丢失 1 秒事务。它只适用于日志表、埋点、非核心状态更新等业务。
绝对不能在涉及资金、订单、账户余额的场景用；更不能和 sync_binlog = 1 搭配——会导致 binlog 和 redo log 不一致，主从复制可能出错。
监控 Innodb_os_log_pending_fsyncs：持续 >0 说明 OS 缓存积压严重，此时设为 2 已经不够用，得查磁盘或 fsync 配置本身。
真正难的不是算公式，而是把 SHOW ENGINE INNODB STATUS 里那几行数字和线上写入毛刺、延迟抖动对应起来——差值、延迟、等待计数，三者缺一不可。很多人调完就跑，却没盯住运行时指标是否真的收敛。
