MySQL 5.7 中 ALTER TABLE ... MODIFY COLUMN 修改 ENUM 字段默认会锁表，因其不支持 ENUM 的 online 元数据变更，必须触发全表重建（COPY DDL），逐行校验存量值是否在新枚举范围内，全程持有 MDL 写锁，阻塞所有读写操作。
ALTER TABLE MODIFY COLUMN 修改 ENUM 会锁表吗
在 MySQL 5.7 中，ALTER TABLE ... MODIFY COLUMN 修改 ENUM 字段定义（比如增删枚举值）**默认会触发表重建（copy DDL）**，即使只是往 ENUM('a','b') 里加一个 'c'。这是因为 MySQL 5.7 不支持 ENUM 的 online 元数据变更，底层需要重写 .frm 文件并逐行校验存量数据是否仍在新枚举范围内。
常见误判是认为“只是改个定义，又没动数据”，但实际执行时：SHOW PROCESSLIST 会长时间显示 altering table，INFORMATION_SCHEMA.INNODB_TRX 可能出现长事务阻塞，主从延迟也会突增。
- 必须提前确认存量数据合法：执行
SELECT DISTINCT col FROM tbl WHERE col NOT IN ('v1','v2','v3');，确保返回空结果 - 避免在业务高峰执行；若表超 100 万行，建议搭配
pt-online-schema-change工具 - 不要依赖
ALGORITHM=INPLACE—— MySQL 5.7 对 ENUM 的 MODIFY 不支持该算法，强制指定会报错ALGORITHM requires LOCK=NONE, but LOCK is not supported for this operation
为什么不能用 CHANGE COLUMN 改 ENUM
CHANGE COLUMN 在语义上要求重申整个字段定义，稍有遗漏就会意外丢失约束。例如原字段是 status ENUM('init','done') NOT NULL DEFAULT 'init'，若写成：
ALTER TABLE orders CHANGE COLUMN status status ENUM('init','done','cancel') VARCHAR(20);
不仅类型写错（VARCHAR(20) 被当成了新类型），还会直接丢掉 NOT NULL 和 DEFAULT —— 因为 CHANGE 是“删除旧列 + 新建同名列”，所有未显式写出的属性都会回归默认值。
- 只改枚举值，一律用
MODIFY COLUMN，不重命名字段 - 如果真要改名+改枚举，分两步：先
MODIFY枚举，再单独CHANGE字段名（且必须完整重写含所有约束） - 执行前务必用
SHOW CREATE TABLE tbl\G备份原始定义，避免重写时漏掉COLUMN_FORMAT或STORAGE等隐式属性
新增枚举值后老数据会变 NULL 吗
不会。MySQL 对存量行不做任何转换，老数据仍按原枚举序号存储（如 'init' 存的是 1），查询时自动映射回字符串。只要新增的枚举值放在末尾（如从 ENUM('a','b') 扩为 ENUM('a','b','c')），原有值始终有效。
但有两个危险边界：
- 如果把新值插在中间，比如改成
ENUM('a','c','b')，原来存'b'（序号 2）的行会变成'c'（新序号 2），数据语义被静默篡改 - 如果删掉某个枚举值（如去掉
'done'），已有数据中该值不会被自动清理，但后续SELECT会显示为空字符串''，且WHERE col = 'done'查不到 —— 这属于“逻辑损坏”，DBA 很难第一时间发现 - MySQL 5.7 不支持
ALTER TABLE ... ALTER COLUMN col SET DEFAULT，设默认值只能靠MODIFY重写整列定义，漏写DEFAULT就等于清空它
字符集和排序规则影响 ENUM 存储吗
不影响。ENUM 值在磁盘上以紧凑整数形式存储（1 或 2 字节），字符串列表仅用于元数据描述和客户端展示。但字符集会影响你写 SQL 时的字面量匹配：
比如表用 utf8mb4_bin 排序，而你执行 UPDATE tbl SET status = 'Done' WHERE status = 'done'，大小写敏感会导致条件不命中 —— 这不是 ENUM 本身的问题，而是字符串比较行为。
- 线上表统一用
utf8mb4_0900_as_cs（MySQL 8.0+）或utf8mb4_unicode_ci（5.7），避免大小写/重音敏感引发的隐性 bug - 枚举值定义里不要混用全角/半角、中英文引号、不可见字符（如
U+200B零宽空格），否则开发查SHOW CREATE TABLE时肉眼难识别差异 - 如果项目已存在大量
ENUM字段，升级到 MySQL 8.0 后注意：8.0.13+ 支持ADD COLUMN ... DEFAULT ... STORED，但 ENUM 不适用此语法，仍走传统路径
真正麻烦的不是加几个枚举值，而是当某天发现 ENUM('pending','success','failed') 里漏了 'timeout'，而表里已有 2000 万行数据、且应用代码已假设这三值穷尽所有状态 —— 此时改 DDL 只是起点，后面还得同步校验数据一致性、灰度验证应用逻辑、更新所有 SQL 模板里的 IN 列表。枚举不是类型安全的银弹，它把部分校验逻辑从应用层移交给了数据库，也把演进成本悄悄提高了。
