mysql 5.7 修改字段类型绝大多数需重建表，因innodb缺乏就地修改能力；必重建场景包括：varchar跨255字节边界、缩容、改字符集、非空表加not null default、数值类型精度变更等。
MySQL 5.7 修改字段类型（如 MODIFY COLUMN 或 CHANGE COLUMN）绝大多数情况下必须重建整张表，不是因为实现偷懒，而是 InnoDB 存储引擎在该版本缺乏对多数结构变更的就地修改能力——它无法安全地复用原有页结构、索引 B+ 树和行格式，只能走「新建临时表 + 全量拷贝 + 原子切换」流程。
哪些 MODIFY COLUMN 操作一定会触发重建？
只要新旧定义导致底层存储格式不兼容，5.7 就无法 in-place 修改，强制走 ALGORITHM=COPY：
-
VARCHAR长度跨越 255 字节边界：例如 utf8mb4 下从VARCHAR(63)（252 字节）改为VARCHAR(64)（256 字节），长度头从 1 字节升为 2 字节，InnoDB 行格式必须重排 - 缩小字段长度：如
VARCHAR(100)→VARCHAR(10)，需逐行校验截断风险，必须读取所有数据 - 改字符集或排序规则：如
CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci，每行字符串需重新编码 - 新增
NOT NULL DEFAULT到非空表：必须回填默认值，无法跳过物理扫描 - 修改数值类型精度或符号性：如
INT→BIGINT或SIGNED→UNSIGNED，字节宽度变化影响行偏移计算
为什么 ALGORITHM=INPLACE 不起作用？
加了 ALGORITHM=INPLACE 也不等于能 inplace，它只是个“申请”，MySQL 会在执行前做可行性检查；一旦发现不支持，就直接报错退出，而不是静默降级：
- 报错示例：
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported - 真正是否 inplace，必须靠
EXPLAIN FORMAT=JSON SELECT 1查执行计划（注意：要对ALTER TABLE语句本身执行 EXPLAIN，不是 SELECT） - 关键字段是
"alter_algorithm": "inplace"和"supports_inplace": true，二者缺一不可 - 即使显示 inplace，末尾的元数据切换阶段仍需短暂加 MDL_EXCLUSIVE 锁，高并发下可能引发瞬时堆积
如何提前预判会不会重建？
别靠猜，按字节算，再验证：
- 查当前字符集：
SHOW CREATE TABLE t，确认是utf8mb4（1 字符 ≤ 4 字节）还是utf8（≤ 3 字节） - 计算旧字段最大字节数 = 原长度 × 单字符最大字节数；新字段同理
- 若旧 ≤ 255 且新 > 255 → 必重建；若两者都 ≤ 255 → 可能不重建（但需验证）
- 快速验证命令：
ALTER TABLE t MODIFY c VARCHAR(N) ALGORITHM=INPLACE, LOCK=NONE;，看SHOW PROCESSLIST中状态是否变成copy to tmp table或直接报错
重建过程到底锁什么、卡多久？
重建不是“慢”，是硬性阻塞——从开始到 RENAME 完成前，全程持有两把锁：
-
MDL_EXCLUSIVE锁：阻止任何新事务获取该表的 MDL_SHARED（包括普通SELECT） - 表级写锁：阻塞所有 DML（
INSERT/UPDATE/DELETE） - 锁持续时间 ≈ 数据拷贝时间 + 索引重建时间，千万行表常达数分钟；期间
SHOW PROCESSLIST里大量连接卡在Waiting for table metadata lock - 长事务是隐形放大器：一个未提交的
SELECT * FROM t FOR UPDATE就能让 DDL 无限等待，因为lock_wait_timeout默认是一年
真正难的不是“能不能改”，而是“改的时候业务还在跑”。哪怕你算准了不会重建，只要没清理掉长事务、没调低 lock_wait_timeout、没监控 INNODB_TRX，DDL 就可能悄无声息卡住一整晚。这不是配置问题，是执行模型决定的刚性约束。
