直接修改 innodb_log_file_size 后重启 MySQL 会失败，因为 InnoDB 启动时严格校验 ib_logfile0/1 文件大小是否与配置值完全一致，不匹配则拒绝启动；正确操作需先停库（innodb_fast_shutdown=0）、删旧日志、改配置、再启动。
直接改 innodb_log_file_size 然后重启 MySQL，99% 会失败——报错 InnoDB: Error: log file ./ib_logfile0 is of different size，MySQL 进程直接退出，服务不可用。
为什么只改配置就重启一定会失败
InnoDB 启动时会严格校验磁盘上已存在的 ib_logfile0、ib_logfile1 文件大小，是否与 my.cnf 中的 innodb_log_file_size 值完全一致。不匹配就是硬性拒绝启动，不是警告，也不是降级运行。
常见误操作包括：
- 只改了配置，没删旧日志文件
- 删了
ib_logfile*，但 MySQL 进程没真正退出（ps aux | grep mysqld还有残留），Linux 下rm只是 unlink，文件实际仍被句柄持有 - 只删了一个文件（如只删
ib_logfile0），但innodb_log_files_in_group = 2，必须两个都清空
停库前必须确认的三件事
避免删错、启不起来、甚至丢数据，操作前务必验证：
- 执行
mysql -e "SET GLOBAL innodb_fast_shutdown = 0"，确保脏页和 checkpoint 全部刷盘（尤其当innodb_fast_shutdown = 2是默认值时） - 用
systemctl stop mysql或mysqladmin shutdown关库，**不要 kill -9** - 检查 error log 最后几行，确认出现
mysqld: Shutdown complete；再跑ps aux | grep mysqld，输出应为空
安全调整的完整操作链
顺序不能乱，跳步等于制造故障：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 备份旧日志：
cp /var/lib/mysql/ib_logfile* /backup/（路径以datadir为准，别直接rm -f） - 确认库已停稳后，删除：
rm /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile1 - 编辑
/etc/my.cnf的[mysqld]段，写入新值，例如：innodb_log_file_size = 512M（注意：必须是 512KB 的整数倍） - 启动：
systemctl start mysql—— 此时 InnoDB 自动创建符合新尺寸的日志文件
启动后立刻验证：SHOW VARIABLES LIKE 'innodb_log_file_size'; 和 ls -lh /var/lib/mysql/ib_logfile*，两者大小必须一致。
调多大才算合理，而不是瞎调
目标不是“越大越好”，而是让 checkpoint age（Log sequence number − Last checkpoint at）稳定在总日志空间的 70% 以下。否则依然会频繁触发 checkpoint，导致写入卡顿。
实操判断方式：
- 查当前写入压力：
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written';，每秒增长量 × 60 × 90 ≈ 推荐总日志容量（按 1.5 小时写入量估算） - 看
SHOW ENGINE INNODB STATUS\G中的 Log section，如果pending log writes长期 > 0，或log write wait明显上升，说明日志已成瓶颈 - SSD + 高并发场景，单文件设
256M–1G较稳妥；HDD 可降至128M，但不宜再小
特别注意：MySQL 8.0.30+ 已将 innodb_log_file_size 标记为 deprecated，若已升级，应改用 innodb_redo_log_capacity 动态控制总容量，且不能再同时配置 innodb_log_file_size，否则报错 Unknown variable 'innodb_log_file_size'。
