MySQL 报 ERROR 1114 (HY000): The table is full 或 OS error code 28: No space left on device，但磁盘明明还有空间？
大概率是 innodb_redo_log_capacity（或旧版本的 innodb_log_file_size × innodb_log_files_in_group）撑满了，且 Redo Log 循环写入卡在 checkpoint 之后——InnoDB 拒绝写新日志，直接堵住所有 DML。
这不是磁盘空间问题，而是 Redo Log 的「有效循环窗口」被占满。InnoDB 不会自动扩容 Redo Log 文件，必须手动调整并重启。
- 5.7 及更早：靠
innodb_log_file_size和innodb_log_files_in_group共同决定总容量；升级到 8.0.30+ 后这两个参数已废弃 - 8.0.30+：统一用
innodb_redo_log_capacity控制（单位字节），推荐设为总内存的 1%–2%，但不低于 100MB - 扩容前必须确保
SHOW ENGINE INNODB STATUS中的Log sequence number和Last checkpoint at差值不大（
MySQL 8.0.30+ 如何安全扩容 Redo Log 容量？
不能在线改 innodb_redo_log_capacity，必须停机操作。关键是：先清空日志、再删旧文件、再改配置、最后重启——顺序错一步就启不来。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 执行
SET GLOBAL innodb_fast_shutdown = 0，让 shutdown 做完整 checkpoint（避免残留脏页） - 正常关闭 MySQL：
systemctl stop mysqld（或mysqladmin shutdown） - 确认 MySQL 进程已退出，然后删除
ib_logfile0、ib_logfile1等所有ib_logfile*文件（路径通常在datadir下） - 修改
my.cnf，增加或更新：innodb_redo_log_capacity = 1073741824（即 1GB） - 启动 MySQL：
systemctl start mysqld—— 启动时会根据该值自动创建新 Redo Log 文件
为什么改完配置 MySQL 启动失败？常见报错和对应检查点
最常卡在 InnoDB: Error: log file ib_logfile0 is of different size 或直接静默退出，本质是残留文件与配置不匹配。
- 没删干净旧
ib_logfile*：哪怕剩一个，InnoDB 就拒绝覆盖，报 size mismatch -
innodb_redo_log_capacity设得太小（Invalid value for innodb_redo_log_capacity - 配置写错位置：比如加在
[client]段而非[mysqld]，导致实际未加载 - 权限问题：MySQL 用户对
datadir目录无写权限，无法生成新 log 文件
Redo Log 扩容后要不要调其他参数？
要，但只动两个关键项。Redo Log 变大后，checkpoint 频率下降，若不调参可能拖慢崩溃恢复速度或堆积过多脏页。
- 增大
innodb_log_checkpoint_now不现实（仅临时触发），真正该调的是innodb_max_dirty_pages_pct（默认 90）——建议降到 75～85，让刷脏更积极 - 观察
Innodb_buffer_pool_pages_dirty和Innodb_buffer_pool_write_requests比值，如果脏页长期 > 10% 缓冲池大小，说明刷盘压力大，需配合调低innodb_io_capacity - 别碰
innodb_flush_log_at_trx_commit：它控制的是刷日志时机，和 Redo Log 总容量无关；设为 2 或 0 虽能提速，但丢数据风险陡增
Redo Log 不是越大越好，扩到 2GB 以上却没配够 innodb_io_capacity，反而会让 checkpoint 拖尾更严重——这点最容易被忽略。
