MySQL 8.0+ 中 ALTER TABLE ADD COLUMN 默认触发元数据更新而非表文件重写；仅当新增字段带 DEFAULT 值、需填充历史数据或不满足 Instant 条件时，才触发 In-Place 或 Copy 算法导致 ibd 文件重写。
ALTER TABLE ADD COLUMN 触发的是 InnoDB 表文件重写还是元数据更新？
取决于 MySQL 版本、字段类型、是否带 DEFAULT 值，以及是否显式指定 ALGORITHM=INPLACE。MySQL 5.6 之后引入 Online DDL，但「加字段」是否重写表文件，不能一概而论。
核心判断逻辑是：如果新增字段不破坏现有行格式（即不改变已有记录的物理布局），且不需填充默认值到历史数据中，则走 In-Place；否则触发 Copy 算法，重建整个表文件。
- MySQL 8.0+ 中，
ALTER TABLE t ADD COLUMN c INT默认走In-Place，只更新数据字典（mysql.ibd中的系统表），不触碰用户数据文件 - 但如果写成
ALTER TABLE t ADD COLUMN c INT DEFAULT 1，MySQL 必须为所有已有行写入默认值 → 触发全表扫描 + 行更新 → 实际上会重写聚簇索引页，ibd文件大小可能增大 - 若字段类型涉及字符集转换（如从
VARCHAR(10)改为VARCHAR(10) CHARACTER SET utf8mb4），即使只是 ADD，也可能强制Copy
ibd 文件里到底发生了什么？不是“改个头文件”那么简单
ibd 是 InnoDB 的独立表空间文件，它不存纯“结构定义”，而是把表结构、索引结构、数据页、undo 日志段都混存在一块连续磁盘区域里。加字段时，真正变动的有三处：
- 系统表空间（
mysql.ibd）中的sys_columns和sys_fields记录被插入新字段元数据 - 用户表的
ibd文件头部的FIL_PAGE_DATA区域更新了表的dict_table_t::n_cols字段数，以及新增字段在dict_col_t中的偏移描述 - 如果走了
In-Place，后续新插入的行会在行首（DB_TRX_ID前）多预留字段空间；老行仍保持旧格式，靠NULL-bitmask和extra-length字段动态解释——这就是为什么查询老行时能“看到”新字段（值为 NULL），但不实际占用存储
为什么有些场景下 ibd 文件大小反而变小了？
这和 InnoDB 的页内碎片回收机制有关，不是加字段本身导致的，而是 Copy 算法执行过程中附带的副作用：
- 当 MySQL 被迫用
Copy方式重建表（比如加带 DEFAULT 的字段），它会重新组织所有数据页：合并半满页、清除已删除记录的 ghost 记录、重排页内 slot 数组 - 如果原表长期经历大量 UPDATE/DELETE，页碎片率高，重建后
ibd可能缩小 10%~20% - 但注意：这个“变小”是重建结果，不是加字段的直接效果；且重建过程会锁表更久、产生更大 binlog，得不偿失
MyISAM 和 InnoDB 在文件层面的差异，直接影响 DDL 行为
MyISAM 完全没事务、没行格式抽象，它的 .MYD（数据）和 .MYI（索引）是纯顺序文件。给 MyISAM 表加字段，必然触发全量复制 —— 因为每一行都是定长结构，加字段等于所有行都要重写。
- MyISAM 的
.frm文件（表定义）会被重写，.MYD文件内容逐行读出、补字段、再写入新文件，最后原子替换 - InnoDB 则利用其行格式灵活性（Compact/Redundant/Dynamic）和事务性数据字典，在多数简单 ADD COLUMN 场景下避免物理复制
- MySQL 8.0 彻底移除了
.frm文件，所有元数据落进mysql.ibd，这也是 InnoDB 能支持原子 DDL 的前提
真正危险的不是“加字段”这个动作本身，而是你没意识到：同一句 ALTER TABLE ... ADD COLUMN，在不同条件下可能走完全不同的底层路径——有的毫秒级，有的锁表两小时。别只看 SQL 表面，得盯住 ALGORITHM、LOCK、是否有 DEFAULT、以及当前表的行格式和碎片状态。
