innodb_log_file_size调整必须停库，因其为只读参数，无法动态修改；需干净关闭MySQL、备份并删除旧日志文件后重启，由InnoDB自动重建，且需验证文件大小与配置一致。
innodb_log_file_size 调整前必须停库
MySQL 的 innodb_log_file_size 是只读配置项，启动时加载后无法动态修改。强行在运行中改配置文件再 SET GLOBAL 会报错 Variable 'innodb_log_file_size' is a read only variable。所以扩容日志不是改个参数 reload 就行，得真停服务。
常见错误是以为像 innodb_buffer_pool_size 那样能在线调——其实不能。InnoDB 日志文件（ib_logfile0、ib_logfile1）是固定大小的循环写入文件，结构在初始化时就固化了，改大小等于重做整个日志系统。
- 必须先正常关闭 MySQL：
mysqladmin shutdown或systemctl stop mysqld - 确认进程已退出：
ps aux | grep mysqld，避免残留进程锁住文件 - 备份原有日志文件（可选但强烈建议）：
cp ib_logfile* /backup/
删旧日志文件前要确保干净关机
如果 MySQL 是 kill -9 强杀或崩溃退出，ib_logfile* 可能处于不一致状态。此时直接删掉再启库，InnoDB 检测到缺失或大小不匹配的日志，会拒绝启动，并报错 InnoDB: Error: log file ib_logfile0 is of different size 或更严重的 Database page corruption。
正确做法是：确保 shutdown 是 clean 的，即 error log 末尾有类似 mysqld: Shutdown complete 的记录。如果不确定，可以用 mysqld --innodb-force-recovery=1 尝试启动并导出数据，再重建实例。
- 不要手动
rm ib_logfile*后直接启动新配置 - 删之前检查 error log 最后几行，确认 shutdown 流程完整
- 若曾异常终止，优先考虑用备份恢复，而非硬调日志参数
调整值不是越大越好，要匹配写负载和恢复时间
innodb_log_file_size 决定单个日志文件大小，总日志容量 = innodb_log_files_in_group × innodb_log_file_size（默认 innodb_log_files_in_group = 2）。调大能减少 checkpoint 频率、提升写吞吐，但也会延长崩溃恢复时间——因为 recovery 阶段要重放所有未刷盘的 redo log。
典型误判是“日志满了就翻十倍”，比如从 48M 直接调到 512M。实际应参考 SHOW ENGINE INNODB STATUS\G 中的 Log sequence number 和 Last checkpoint at 差值，估算每分钟产生多少 log。一般生产环境单个文件设为 256M–1G 较稳妥。
- 高并发写入场景（如订单库）：可设为 512M，配合
innodb_log_files_in_group = 2→ 总 1G - 低频更新小库：128M 足够，避免 recovery 时间无谓拉长
- 调完首次启动会自动重建日志文件，耗时取决于磁盘速度，期间不可连库
配置生效后要验证日志文件是否重建成功
重启后不能只看 MySQL 是否起来，得确认新 ib_logfile* 真按预期大小生成了。常见疏漏是配置写错位置（比如加在 [client] 段）、或 mysqld 实际加载的是另一个 cnf 文件（用 mysqld --verbose --help | grep "Default options" 查找真实配置路径）。
验证方法很简单：
- 进 datadir：
ls -lh ib_logfile*，大小应与innodb_log_file_size值一致 - 查运行值：
SELECT @@innodb_log_file_size;，输出数字需匹配配置 - 看 error log 启动行：会有类似
InnoDB: Setting log file ib_logfile0 size to 536870912 bytes
最常被忽略的一点：如果用 systemd 管理，改完 /etc/my.cnf 后没 reload daemon，systemctl 仍可能读旧缓存，导致配置不生效。记得 systemctl daemon-reload。
