不能平滑调整，必须停库、删旧文件、改配置、重启；InnoDB 启动时严格校验 ib_logfile0/1 大小与 innodb_log_file_size 配置是否一致，不匹配则硬性拒绝启动，常见报错为“InnoDB: Error: log file ./ib_logfile0 is of different size”。
直接说结论：不能平滑调整，必须停库、删旧文件、改配置、重启。所谓“平滑”在这里是伪命题，InnoDB 对 ib_logfile0 和 ib_logfile1 的大小极其敏感，任何在线修改都会导致启动失败，报错 InnoDB: Error: log file ./ib_logfile0 is of different size。
为什么改了 innodb_log_file_size 启动就失败
MySQL 启动时，InnoDB 会校验磁盘上已存在的 ib_logfile0 和 ib_logfile1 是否与配置中声明的 innodb_log_file_size 严格匹配。不匹配就拒绝启动——这不是警告，是硬性拒绝。常见错误日志里会出现 log file size mismatch，根本原因是旧日志文件没清干净，或者配置改了但没删文件。
- 误操作：只改
my.cnf然后service mysqld reload或kill -HUP—— 无效，InnoDB 不支持热重载该参数 - 删错方式：用
mv ib_logfile0 ib_logfile0.bak而不是rm—— InnoDB 仍会检测到同名文件（哪怕加了后缀），依然报错 - 遗漏文件：只删了
ib_logfile0，忘了ib_logfile1（默认两个）
安全停库前必须做的三件事
停库不是简单执行 mysqladmin shutdown 就完事。如果实例还有未提交事务或长连接正在写入，强制关库可能损坏日志一致性，后续无法启动。
- 先执行
SET GLOBAL innodb_fast_shutdown = 0：确保所有脏页刷盘、undo 日志清理完毕，避免崩溃恢复出问题 - 确认无活跃事务：
SELECT * FROM information_schema.INNODB_TRX;返回空结果才算安全 - 检查连接状态：
SHOW PROCESSLIST;中不应有Query状态且Command为Sleep但Time极长的连接（可能正持锁未提交）
删文件 + 改配置 + 启动的实操要点
操作顺序和细节决定成败。以下步骤适用于 MySQL 5.6 及以上（包括 8.0），无需手动 mv 备份，但必须彻底删除：
- 停库命令用
mysqladmin --user=root --password=xxx shutdown，不要kill -9进程 - 进
datadir目录（可通过SELECT @@datadir;查），执行rm ib_logfile*—— 注意是rm，不是mv或rename - 编辑
my.cnf，在[mysqld]段落添加或修改：innodb_log_file_size = 512M（建议值：256M–2G，按峰值 1–2 分钟写入量估算） - 启动服务：
systemctl start mysqld或mysqld_safe --defaults-file=/etc/my.cnf --user=mysql &；启动成功后，ls -lh ib_logfile*应显示新大小
调大后要注意的副作用
增大 innodb_log_file_size 是性能优化手段，但不是没有代价：
- 崩溃恢复时间变长：因为需要重放更多 redo log，若设置为 4G，恢复可能多花几十秒——对高可用架构需评估 RTO
- 别乱动
innodb_log_files_in_group：默认 2 即可；调它不解决容量瓶颈，真正起作用的是innodb_log_file_size × innodb_log_files_in_group的乘积 - 首次启动会慢一点：InnoDB 要初始化新日志文件，属正常现象，不必干预
最容易被忽略的一点：很多人查完 SHOW VARIABLES LIKE 'innodb_log_file_size' 就以为生效了，其实那只是配置值；真正生效要等重启后看 ls -lh ib_logfile* 文件大小，以及观察 COMMIT 延迟是否下降。日志文件尺寸不匹配的问题，从来不是配置错了，而是删得不干净。
