修改 innodb_log_file_size 必须停库后删除旧日志文件再重启，5.6.8+ 不支持在线调整；8.0.30+ 应改用 innodb_redo_log_capacity 动态设置总容量。
修改 innodb_log_file_size 前必须停库，且不能直接改配置重启
MySQL 5.6.8 之后版本（含 5.7/8.0）不支持在线调整 innodb_log_file_size，强行改配置后重启会报错 InnoDB: Error: log file ./ib_logfile0 is of different size，服务直接启动失败。
正确做法是：先停 MySQL → 手动删除旧日志文件 → 再改配置 → 最后启动。删文件前务必确认实例已完全停止（ps aux | grep mysqld 无残留进程），否则可能损坏数据。
- 旧日志文件默认在数据目录下，名字是
ib_logfile0、ib_logfile1（数量由innodb_log_files_in_group决定） - 删除前建议备份：
cp ib_logfile* /backup/（虽不能用于恢复，但可辅助诊断） - 如果启用了
innodb_fast_shutdown = 2（默认值），需先执行SET GLOBAL innodb_fast_shutdown = 0再关库，确保脏页和日志刷干净
innodb_log_file_size 不是越大越好，得看写入压力和恢复时间
增大 innodb_log_file_size 能减少 checkpoint 频率、缓解“log file full”等待，但副作用也很实在：崩溃恢复时间变长（MySQL 启动时要重放所有未刷盘的 redo 日志），而且单个日志文件最大不能超过 512GB（8.0.30+ 放宽到 4TB，但实际极少用到）。
典型参考值：innodb_log_file_size × innodb_log_files_in_group ≈ 1–2 小时的写入量。例如写入峰值 100MB/s，按 1.5 小时算，总日志空间需约 540GB → 若保持默认双日志（2 个），则设为 innodb_log_file_size = 270G；若只想要 256MB 单日志，则总空间仅 256MB，checkpoint 会非常频繁。
- OLTP 场景常见设置：128M–1G（配合
innodb_log_files_in_group = 2） - SSD + 高并发写入可上 2G–4G，但必须同步压测崩溃恢复时间
- 如果
SHOW ENGINE INNODB STATUS中看到大量Log sequence number和Last checkpoint at差距持续接近 80% 以上，说明日志太小
MySQL 8.0+ 的新限制：改大小必须匹配 innodb_redo_log_capacity
8.0.30 起引入了动态 redo 日志机制，innodb_log_file_size 被标记为 deprecated，推荐用 innodb_redo_log_capacity 控制总容量（单位字节）。但二者不能混用：如果设置了 innodb_redo_log_capacity，再配 innodb_log_file_size 会触发启动错误 Unknown variable 'innodb_log_file_size'。
升级到 8.0.30+ 后想调大日志空间，应改用：
SET PERSIST innodb_redo_log_capacity = 1073741824; -- 1GB
该变量可动态生效（无需重启），但实际扩容仍需满足：当前总 redo 空间利用率
- 查看当前使用率：
SELECT * FROM performance_schema.innodb_redo_log_files; - 降级操作（减小容量）不支持，只能停库重建
- 如果误配了两个参数，MySQL 启动会失败，错误日志里明确提示冲突
别漏掉 innodb_log_buffer_size 的协同调整
innodb_log_buffer_size 是内存中写 redo 的缓冲区，默认 16MB。它和 innodb_log_file_size 是上下游关系：buffer 满了或事务提交时，才批量刷进磁盘日志文件。如果 buffer 太小，会导致频繁刷盘，抵消大日志文件带来的优化效果。
一般规则：当单事务产生 redo 超过 1MB（比如大批量 INSERT ... SELECT 或大 BLOB 更新），就该调高 buffer。但没必要超过 64MB，因为它是全局独占内存，过大反而浪费。
- 常见搭配：日志文件设为 512MB 时，buffer 可设为 32M–64M
- 观察指标：
innodb_os_log_written（每秒写入量）突增 +innodb_log_waits> 0，说明 buffer 经常不够用 - 注意：该参数不能动态修改，必须写入配置文件并重启
改完配置不是一劳永逸。真正影响性能的是日志循环写入节奏和崩溃恢复表现，上线前一定要在备库或测试环境模拟一次断电重启，看恢复耗时是否在容忍范围内。很多人卡在“为什么调大了反而启动慢十分钟”，就是没做这步验证。
