innodb_log_file_size 设置不当会导致启动失败
MySQL 5.6.8 之后版本中，
innodb_log_file_size修改后不能直接重启生效，必须先停库、删除旧日志文件、再启动，否则会报错
InnoDB: Error: log file ./ib_logfile0 is of different size。
实操建议：
修改前先确认当前值：SHOW VARIABLES LIKE 'innodb_log_file_size';停库后手动删除
ib_logfile0和
ib_logfile1（路径由
innodb_log_group_home_dir决定，默认是数据目录） 确保
innodb_log_file_size × 2不超过 512GB（InnoDB 硬限制） 线上调大该值可减少 checkpoint 频率，但恢复时间变长；一般设为 1–4GB，取决于写入压力和恢复 RTO 要求
innodb_flush_log_at_trx_commit=2 时 crash 可能丢一秒事务
这个参数控制日志刷盘策略：
1是每次事务都
fsync到磁盘（最安全），
0是每秒刷一次（性能最好但最多丢一秒），
2是写入 OS cache 后即返回（折中，但 OS 崩溃仍可能丢事务）。
常见误用场景：
误以为2是“既快又不丢数据”，其实只要 MySQL 进程没挂但 OS 挂了（如断电），未刷盘的日志就丢了 主从架构下，若从库也设为
2，可能导致主从数据不一致（主库已提交，从库因 crash 丢失） SSD + ext4/xfs +
barrier=1可缓解但不能消除风险
ibdata1 文件持续增长且无法收缩
ibdata1是 InnoDB 共享表空间，默认存放数据字典、undo logs、系统回滚段。一旦写入，即使删掉大量表，它也不会自动缩小——这是 InnoDB 的设计限制。
避免方案（需提前规划）：
初始化实例时启用innodb_file_per_table=ON（5.6+ 默认开启），让每个表独占一个
.ibd文件，便于单表清理与迁移 禁用共享表空间的 undo log 存储：MySQL 5.7+ 支持
innodb_undo_tablespaces和
innodb_undo_directory，把 undo 分离到独立文件 已膨胀的
ibdata1只能通过 mysqldump 全量导出 → 删除数据目录 → 重建实例 → 导入来回收空间
redo log 与 binlog 不一致引发主从异常
MySQL 主从依赖
binlog复制，而崩溃恢复依赖
redo log。两者内容不同步时（例如 binlog 写成功但 redo 未刷盘），可能导致从库应用了主库实际未提交的事务。
关键防护措施：
必须开启sync_binlog=1和
innodb_flush_log_at_trx_commit=1，并确保
innodb_support_xa=ON（5.7.7+ 已默认启用 XA） 检查是否启用了
innodb_safe_truncate（影响 DDL 安全性，但非日志核心） 用
mysqlbinlog --base64-output=DECODE-ROWS -v对比主库 binlog 与从库 relay log 的 GTID 或 position 是否对齐 配置项之间有隐式耦合，比如调大
innodb_log_file_size后若忘记调整
innodb_log_buffer_size，高并发小事务反而更容易触发日志缓冲区 flush。这些细节不报错，但会让优化效果打折扣。
