直接看Innodb_os_log_written增速和Innodb_log_waits是否异常增长：前者反映每秒真实写入量，后者为“等日志空间”次数，只要>0且持续上升，就说明Redo Log已成瓶颈。
怎么看Redo Log是否正在拖慢写入
直接看 Innodb_os_log_written 增速和 Innodb_log_waits 是否异常增长。前者反映每秒真实写入量，后者为“等日志空间”次数——只要它非零且持续上升，就说明 Redo Log 已成瓶颈。
执行两次：SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_os_log_written';，间隔 30 秒，差值 ÷ 30 得出 B/s。若峰值超 30MB/s 但 Innodb_log_waits 频繁跳变，基本可断定日志容量或刷盘能力跟不上。
- 查等待：运行
SHOW GLOBAL STATUS LIKE 'Innodb_log_waits';，值 > 0 就危险 - 查错误日志：grep “Waiting for redo log space” 或 “log write error”，有则立刻停写排查磁盘或权限
- 别只盯平均值：用
mysqladmin ext -i1 | grep Innodb_os_log_written实时观察脉冲式尖峰，OLTP 场景下短时 80MB/s 很常见
为什么调大 innodb_redo_log_capacity 后反而更卡
容量不是越大越好。MySQL 8.0.30+ 的 innodb_redo_log_capacity 单位是字节，设错会直接导致崩溃恢复变慢、提交延迟飙升——因为 InnoDB 要扫描全部容量找有效日志段，而非只读实际写入部分。
- 实测写入 18MB/s，RTO 要求 5 分钟 → 合理值 ≈ 18 × 1024 × 1024 × 300 =
5505024000（约 5.1GB），不是拍脑袋填8589934592（8GB） - SSD 环境可压缩 20%～30%，HDD 则建议上浮 10%～20% 避免 checkpoint 过密
- 在线调整后必须验证：执行
SHOW ENGINE INNODB STATUS\G，检查Log sequence number和Last checkpoint at差值是否长期 > 70% 总容量；若接近，说明还是太小
innodb_flush_log_at_trx_commit=1 是不是真瓶颈
是，尤其在未显式事务包裹的批量 INSERT 或 LOAD DATA 场景下。innodb_flush_log_at_trx_commit = 1 强制每次提交都 fsync，而 8.0 的 log_writer/log_flusher 线程模型 + 两阶段提交（binlog 开启时）会让这个开销被放大。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 确认 binlog 是否开启：
SELECT @@log_bin;，若为 ON，则innodb_flush_log_at_trx_commit = 1实际触发两次同步 I/O（redo + binlog） - 临时缓解：导入/压测前设
SET GLOBAL innodb_flush_log_at_trx_commit = 2;，并配SET GLOBAL sync_binlog = 0;（或启动时加--skip-log-bin） - 注意：session 级设置无效——客户端连接可能新开 session，必须 global 级生效
- 恢复后务必切回 1，否则断电可能丢事务
如何验证 Redo Log 刷盘能力是否真跟不上
光看参数没用，得盯住 SHOW ENGINE INNODB STATUS\G 输出里的三个差值：
-
Log flushed up to和Log written up to差值长期 > 100MB → 日志缓冲区（innodb_log_buffer_size）或底层 I/O 吞吐不足，考虑调大 buffer（默认 16MB，高并发可试 64MB）或换 NVMe -
Log written up to和Log sequence number差值大 → mtr 提交太快，log buffer 来不及拷贝，8.0 的 recent_written 机制可能被压穿 - 结合
iostat -x 1观察日志文件所在磁盘的await（平均IO等待毫秒）和%util，若 await > 10ms 或 %util 持续 > 95%，说明磁盘已饱和，不是 MySQL 配置问题
真正容易被忽略的是：Redo Log 性能瓶颈从来不是单点问题。它藏在写入速率、RTO 目标、存储介质顺序读能力、以及 binlog 同步策略的咬合缝隙里——少盯一个维度，调参就只是把压力从一处转移到另一处。
