不能直接用 MODIFY COLUMN 追加 ENUM 值，因其会触发全表重建，且对历史非法值静默转为空字符串而不报错，导致数据异常与线上事故。
ENUM 字段追加新选项不是“加一个值”那么简单，直接 ALTER TABLE ... MODIFY COLUMN 会触发全表重建，且若存量数据中存在被删除或未覆盖的枚举值（哪怕只是历史残留），MySQL 可能静默转为 ''（空字符串）而不报错——这是线上事故高发点。
为什么不能直接用 MODIFY COLUMN 追加枚举值？
MySQL 对 ENUM 的修改本质是列类型重定义，而非“增量更新”。执行类似 ALTER TABLE t MODIFY status ENUM('active','inactive','pending','archived') 时：
- 若原定义是
ENUM('active','inactive')，而某行status存的是'pending'（比如之前手工绕过校验写入、或旧版应用逻辑残留），该值会被强制截断为''，且sql_mode若未启用STRICT_TRANS_TABLES，不会报错 - 所有行都会被重写，锁表时间与表大小正相关；在千万级表上可能阻塞写入数十秒甚至分钟
- 主从复制中，DDL 执行期间若发生主库切换，从库可能因数据不一致卡住
安全追加的三步验证法
核心原则：先查、再扩、后验。不跳过任何一步。
- 查存量值是否全在新枚举范围内：
SELECT DISTINCT status FROM t WHERE status NOT IN ('active','inactive','pending','archived');
结果非空？说明有非法值，必须先清洗或映射（如把旧的'deleted'统一转成'archived'） - 确认字符集和排序规则兼容：
SHOW FULL COLUMNS FROM t LIKE 'status';
检查Collation是否与新枚举值一致（尤其含中文或特殊符号时），避免隐式转换失败 - 用
ALTER TABLE ... CHANGE COLUMN显式重定义（比MODIFY更可控）：ALTER TABLE t CHANGE status status ENUM('active','inactive','pending','archived') DEFAULT 'active';
注意：必须写出完整枚举列表，不能只写新增项；DEFAULT建议显式指定，避免依赖旧定义
如何避免应用层突然读到空字符串？
即使 DDL 成功，应用代码也可能因缓存、连接池复用或 ORM 映射未刷新，把 '' 当作合法值处理。关键防御点：
- 上线前在测试环境用真实数据集跑一遍
SELECT ... WHERE status = ''，确认无业务意义的空值 - 应用侧对
ENUM字段读取做兜底判断：
Python（PyMySQL）示例：if row['status'] == '':<br> raise ValueError(f"Invalid ENUM value in status: {row}") - 监控慢日志和错误日志中是否出现
Data truncated for column（错误码1265），这是静默截断的唯一线索
长期建议：别让 ENUM 承担动态扩展职责
真正需要频繁增删选项的场景（如用户标签、内容分类），ENUM 天然不适合。它适合的是「几乎不变」的状态字段（如订单状态 'created','paid','shipped','delivered','cancelled'）。一旦发现半年内修改超 2 次，就该评估迁移到外键关联小表——虽然多一次 JOIN，但规避了 DDL 风险、支持注释、可审计、还能加 is_active 开关。这点容易被忽略，但恰恰是架构演进中最常踩的坑。
