不能直接修改 innodb_log_file_size，因为MySQL启动时会校验redo log文件实际大小与配置值是否一致，不一致则拒绝启动并报错；必须停库、清旧日志、改配置后重启。
为什么不能直接改 innodb_log_file_size？
MySQL 启动时会校验 redo log 文件实际大小和配置值是否一致。如果只改配置不处理旧文件，mysqld 会拒绝启动，并报错：InnoDB: Error: log file ./ib_logfile0 is of different size。这不是警告，是硬性失败。
根本原因：InnoDB 在初始化阶段读取日志头（log header），其中包含日志文件大小元数据；若与 innodb_log_file_size 不符，认为日志损坏或配置错误，直接 abort。
- 必须停库操作，无法在线调整
- 修改前需确保所有事务已刷盘（
FLUSH LOGS或正常关闭） - 旧
ib_logfile*文件必须手动删除（或重命名备份），否则新实例仍会尝试加载它们
调整步骤：停库 → 清日志 → 改配置 → 启动
典型安全流程（以从 48MB 调整为 256MB 为例）：
- 执行
mysql -e "SET GLOBAL innodb_fast_shutdown = 0"，确保干净关闭（刷脏页、写 checkpoint） - 停止 MySQL：
systemctl stop mysqld（或对应服务名） - 备份并移除旧日志：
mv ib_logfile0 ib_logfile1 /tmp/（不要用rm -f，留痕防误） - 修改
my.cnf中的innodb_log_file_size = 268435456（单位字节，256MB） - 启动：
systemctl start mysqld—— 此时 InnoDB 自动创建新大小的日志文件
注意：innodb_log_file_size 是单个文件大小，不是总和。默认双文件（innodb_log_files_in_group = 2），所以总 redo log 空间 = 2 × 配置值。
innodb_log_file_size 设多大才合适？
目标是让 checkpoint 活跃区间（checkpoint age）稳定在 innodb_log_file_size × innodb_log_files_in_group × 0.7 以下，避免频繁 checkpoint 带来的写放大。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
实操判断依据：
- 查当前压力：
SHOW ENGINE INNODB STATUS\G，关注Log sequence number和Last checkpoint at差值（即 checkpoint age） - 若该差值长期 > 总日志空间的 70%，说明日志太小，触发 too much checkpoint（见
Logsection 中的pending log writes上升） - SSD 场景下，单文件建议 ≥ 256MB；HDD 可适当降低（如 128MB），但不宜
- 超大写入场景（如批量导入），可设到 1GB+，但需同步调大
innodb_log_buffer_size（通常 4–16MB 足够）
调大后反而写入变慢？检查这几个点
增大 innodb_log_file_size 本应降低 checkpoint 频率、提升吞吐，但如果观察到写入延迟上升，大概率是以下问题：
- 没清空旧日志文件就启动，MySQL 实际仍在用小文件，但配置已变 → 报错或静默降级（取决于版本）
-
innodb_flush_log_at_trx_commit = 2或0被误设，掩盖了日志 I/O 真实瓶颈（应保持1测真实性能） - 磁盘 I/O 能力不足：日志文件变大后，checkpoint 写入单次数据量更大，若磁盘带宽/IOps 不足，反而拉长刷盘时间
- 系统 page cache 不足：大日志文件更依赖 OS 缓存，
vm.swappiness过高或内存紧张会导致频繁换页
最易忽略的一点：调整后未验证日志文件真实大小。用 ls -lh ib_logfile* 确认，别只信配置文件。
