如何分析MySQL因redo log容量满引发的Write stall挂起现象？

直接看SHOW ENGINE INNODB STATUSG的LOG段，对比Log sequence number与Last checkpoint at差值是否长期超innodb_redo_log_capacity（8.0.30+）或innodb_log_file_size×innodb_log_files_in_group（旧版）的70%，且pending log writes持续非零，即可确认redo log容量不足导致Write stall。

怎么看是不是redo log容量满导致的Write stall

直接看 SHOW ENGINE INNODB STATUSG 输出里的 LOG 段，重点盯三个值：Log sequence number、Log flushed up to、Last checkpoint at。用前两者差值算出「当前已用日志量」，再和 innodb_redo_log_capacity（8.0.30+）或 innodb_log_file_size × innodb_log_files_in_group（旧版）比——如果差值长期 > 70% 容量，且 pending log writes 持续非零，基本就是 redo log 跑不过 checkpoint，InnoDB 主动 stalling 写入了。

别被错误码误导：ERROR 1114 (HY000): The table is full 几乎从不来自 redo log 满，而是 tmpdir 满、ibdata1 无 autoextend 或长事务占 undo；真正由 redo log 压力引发的挂起，往往没报错，只有慢、卡、SHOW PROCESSLIST 卡住、写操作超时。

为什么改大 innodb_redo_log_capacity 后 MySQL 启不动

最常见原因是旧 ib_logfile* 文件没删干净，或者配置没生效。InnoDB 启动时会严格校验：文件大小必须和 innodb_redo_log_capacity 完全匹配，哪怕剩一个 ib_logfile0，也会报 InnoDB: Error: log file ib_logfile0 is of different size 并退出。

1. 确认已执行 SET GLOBAL innodb_fast_shutdown = 0，再用 SHUTDOWN 命令关库（不是 systemctl stop），确保 checkpoint 写完、脏页刷净
2. 关库后检查进程是否彻底退出：ps aux | grep mysqld 应无残留；再确认 datadir 下所有 ib_logfile* 文件已被删除（路径用 SELECT @@datadir 查）
3. 配置必须加在 [mysqld] 段下，不能写进 [client]；数值单位是字节，比如 innodb_redo_log_capacity = 1073741824 表示 1GB
4. 启动前检查 MySQL 用户对 datadir 有写权限，否则无法生成新日志文件

扩容后要不要调其他参数

要，但只动两个关键项。redo log 变大后，checkpoint 频率天然下降，若不配套调整，可能拖慢崩溃恢复速度，或让 buffer pool 脏页堆积过多，间接影响性能。

innodb_max_dirty_pages_pct 建议从默认 75 降到 50–60，加快脏页刷出节奏；innodb_io_capacity 和 innodb_io_capacity_max 需按实际磁盘 IOPS 调整（如 NVMe 盘可设为 2000/4000），否则 page cleaner 跟不上写入节奏，照样卡 checkpoint。

别碰 innodb_flush_log_at_trx_commit 来“缓解压力”——它解决的是持久性与性能权衡，不是容量问题。设成 0 或 2 只会让数据更不安全，不减少 redo log 的实际占用压力。

磁盘空间够，但 redo log 还是写不进去

这是最容易忽略的点：redo log 默认放在 datadir 下（如 /var/lib/mysql/），而很多人只监控 /var 分区剩余空间，却没注意 datadir 实际挂载点可能是单独的逻辑卷或目录。用 df --output=source,target,pcent $(mysql -Nse "SELECT @@datadir") | tail -n1 精准查对应挂载点使用率，阈值建议设 85%，别等 95% 才报警——因为 redo log 是循环覆盖，文件大小不变，inotifywait 监听文件变化完全无效，只能靠定时 df 抽样。

另外，ib_logfile* 本身不能清理、不能轮转、不能 logrotate，能安全删的只有 slow_query_log_file 和 general_log_file（删前先 SET GLOBAL slow_query_log = OFF）。误删 ib_logfile 会导致启动失败，报错类似 InnoDB: The log sequence number in ibdata files does not match。