MySQL不建议用ENUM，核心原因是ALTER TABLE MODIFY ENUM会触发全表重建和逐行校验，导致长时间锁表；枚举顺序变更易引发语义错乱；弱类型语言和ORM使用索引值更易踩坑；推荐用TINYINT+应用层枚举或CHECK约束替代。
MySQL 中不建议用 ENUM，核心原因不是它“不能用”，而是后期扩展字段时的 ALTER TABLE 操作会锁表、重建、校验全量数据，代价远超预期。
ALTER TABLE MODIFY ENUM 会触发全表重建
哪怕只是往 ENUM('active', 'inactive') 末尾加一个 'pending'，MySQL 也必须逐行检查现有值是否仍在新枚举范围内。如果表有 500 万行，这个操作可能持续数分钟甚至更久，并全程持有写锁。
- 不是“元数据修改”，而是物理重建：InnoDB 会创建临时表、拷贝数据、校验、重命名
- 即使新加的值在末尾，旧值顺序未变，MySQL 仍需遍历所有行确认无非法值（比如残留的
'archived'） - 若原字段允许
NULL或有默认值，还额外增加默认填充逻辑
枚举值顺序变动会导致语义错乱
ENUM 内部按定义顺序存为整数（'a'→1，'b'→2），但业务代码或应用层若误用数字索引（如 WHERE status = 2），后续调整顺序就会翻车。
- 把
ENUM('draft','published')改成ENUM('draft','reviewing','published')后，原status = 2就从'published'变成'reviewing' - PHP/Python 等弱类型语言中，
INSERT ... VALUES(2)和VALUES('published')行为完全不同，极易踩坑 - ORM（如 Hibernate、MyBatis）若配置为
@Enumerated(EnumType.ORDINAL)，也会因顺序变更导致数据错位
替代方案比硬扛 ENUM 更可持续
用关联表或整型字段替代 ENUM，扩展成本从“停服改表”降为“单条 INSERT”。
- 状态类字段优先用
TINYINT UNSIGNED+ 应用层枚举类（Java 的enum、Go 的iota），查库用数字，传参/展示用语义名 - 需要多语言或动态管理的场景，建
status_types表，主键自增 ID，字段存 code（如'pending'）和 label（JSON 多语言） - 若坚持用字符串约束，可用
CHECK约束（MySQL 8.0.16+）：status VARCHAR(20) CHECK (status IN ('active','inactive','pending'))，改起来只需ALTER TABLE ... DROP CHECK ... ADD CHECK ...
真正麻烦的从来不是“加一个值”，而是加值时没人记得通知 DBA、没人在意那条凌晨三点跑的 ALTER 语句会让订单服务雪崩——这种隐性耦合，才是 ENUM 最难 debug 的地方。
