mysql 5.7中alter table强制走copy模式是设计行为而非bug，因操作不满足online ddl就地修改条件时必退化为新建临时表→全量拷贝→重建索引→原子重命名流程，全程锁表且生成大量临时文件。
ALTER TABLE 触发全表复制是 MySQL 的默认 fallback 行为，不是 bug，而是设计使然。只要操作类型不被当前版本的 Online DDL 规则判定为“可就地修改”，MySQL 就会退回到 COPY 算法：新建临时表 → 逐行拷贝数据 → 重建索引 → 原子重命名。这个过程必然生成大量临时文件，且无法绕过。
哪些 ALTER 操作一定会走 COPY 模式
MySQL 不按“看起来轻量”来判断，而严格依据字段定义变更是否影响物理存储格式或需初始化值：
-
ADD COLUMN xxx INT NOT NULL（无DEFAULT）：每行必须填默认值，强制全表扫描+更新，哪怕只加一列 -
MODIFY COLUMN name VARCHAR(255) → VARCHAR(1024)：长度头从 1 字节升为 2 字节，InnoDB 无法 in-place 扩展已有记录 -
ALTER TABLE ENGINE=InnoDB或CONVERT TO CHARACTER SET utf8mb4：引擎/字符集切换不支持ALGORITHM=INPLACE，直接报错或强制 COPY -
CHANGE COLUMN或MODIFY COLUMN改类型时隐含NOT NULL约束变更（如从允许 NULL 变为 NOT NULL）：触发全表校验与填充
临时文件到底写在哪、为什么调大 tmp_table_size 没用
关键误区：tmp_table_size 控制的是 SQL 层内存临时表上限，和 DDL 临时文件完全无关。真正起作用的是：
- 临时表文件（如
#sql-ib-xxx、#sql-xxx）默认落在原表所在目录，即datadir下对应数据库子目录里，不是tmpdir -
innodb_tmpdir只影响 InnoDB 内部排序/索引构建的临时段，不接管 DDL 产生的 #sql-xxx 文件 - 错误
Temporary file write failure几乎总是因目标挂载点空间不足、inode 耗尽、或挂载选项（如noexec）拒绝写入导致
如何提前预判会不会 COPY、以及能否安全执行
别猜，用 EXPLAIN FORMAT=JSON 实际验证：
- 执行
EXPLAIN FORMAT=JSON ALTER TABLE t ADD COLUMN c1 INT，检查输出中是否同时存在"alter_algorithm": "inplace"和"lock": "none" - 若出现
"supports_inplace": false或"alter_algorithm": "copy"，说明必走全表复制，此时应放弃直连执行 - 即使显示
inplace，也要注意末尾的元数据切换阶段仍需短暂 MDL_EXCLUSIVE 锁——高并发下可能卡住后续 DML
最易被忽略的一点：COPY 模式不仅吃磁盘空间，还会让 binlog 爆增（每行 INSERT 都记一条 event），从库可能因 IO 或日志轮转失败直接 hang 住。线上执行前，务必确认从库磁盘余量、max_binlog_size 设置、以及是否有正在运行的长事务持有 MDL_SHARED 锁。
