Innodb_log_waits持续增长和Log checkpoint age长期超总容量70%即表明redo log写满卡写入；前者反映buffer溢出，后者指向总容量不足，需结合写入速率与配置加载状态精准定位根因。
直接看 Innodb_log_waits 和 Log checkpoint age，这两个值一涨，基本就是 redo log 写满在卡写入。
查 Innodb_log_waits 是否持续增长
这个状态变量是“写入被堵住”的第一手证据。只要它在稳定上升（比如 30 秒内涨了 3+），说明事务提交时被迫等日志刷盘——不是磁盘慢，而是 buffer 溢出或 redo log 总容量不够。
- 执行
SHOW GLOBAL STATUS LIKE 'Innodb_log_waits';，记下数值 - 等 30 秒再查一次，差值 > 0 就要干预
- 如果差值经常是 5–20，大概率是
innodb_log_buffer_size太小，先调大（建议从 32MB 起，按写入峰值的 1–2 秒缓冲量设） - 如果差值为 0，但写入还是卡，问题就转向总容量 —— 往下看
Log checkpoint age
看 SHOW ENGINE INNODB STATUS\G 里的 Log checkpoint age
输出中 LOG 段里这行最关键：Log sequence number - Last checkpoint at。这个差值就是当前活跃 redo log 空间大小，即 checkpoint age。
- 用
SELECT @@innodb_redo_log_capacity;查总容量（MySQL 8.0.30+） - 如果 checkpoint age 长期 > 总容量的 70%，说明 checkpoint 跟不上写入，InnoDB 会主动 stall 所有 DML 来强制刷脏页
- 注意：不要只看单次快照，要观察 5 分钟内是否反复逼近上限；偶尔冲高不算，持续高位才是真问题
- 此时
Innodb_os_log_written的写入速率（差值 ÷ 时间）也得同步查，用来判断该调大还是调小innodb_redo_log_capacity
确认是不是 innodb_redo_log_capacity 配错导致启动失败或无效
MySQL 8.0.30+ 已废弃 innodb_log_file_size，保留它会导致启动报 Unknown variable 'innodb_log_file_size'；但很多人升级后没清理旧配置，结果参数根本没生效，还在用默认 100MB 硬扛高写入。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 检查
my.cnf：确保innodb_redo_log_capacity出现在[mysqld]段，且没被注释 - 确认是否加载：执行
SELECT @@innodb_redo_log_capacity;，返回值必须是你设的数字，不是 104857600（即 100MB） - 如果改了配置但值没变，常见原因是配置写错段（如进了
[client]）、文件权限不对、或 MySQL 启动时没读这个 my.cnf（用mysqld --help --verbose | grep "Default options"确认路径） - 在线修改支持，但调小不会立刻释放磁盘空间——旧日志文件要等自然归档后才删，别误以为调小失败
别漏掉 innodb_flush_log_at_trx_commit 的干扰
这个参数设成 1 时，每次 commit 都 fsync，会显著放大 redo log 压力。尤其在批量导入或高并发小事务场景下，它和过小的 innodb_redo_log_capacity 一起作用，会让写入停顿更频繁、更剧烈。
- 查当前值：
SELECT @@innodb_flush_log_at_trx_commit; - 如果是 1，且业务能接受最多 1 秒数据丢失，临时设为 2：
SET GLOBAL innodb_flush_log_at_trx_commit = 2; - 注意：设为 2 后，必须同步关掉
sync_binlog或设为 0，否则两阶段提交仍会卡在 binlog 刷盘上 - 切回 1 一定要在业务低峰做，并验证 error log 里有没有 “Flushed up to” 追上 “Log sequence number”
真正难的不是调哪个数，而是分清现象背后的层级：buffer 溢出、总容量不足、刷盘策略太激进，三者症状相似但根因不同。盯住 Innodb_log_waits 和 Log checkpoint age 这两个指标，再交叉验证写入速率和实际配置加载状态，才能避开“调了参数但问题还在”的陷阱。
