不建议用 ENUM 存动态数据，因其每次增删值需 ALTER TABLE MODIFY ENUM，触发全表重建、逐行校验并全程锁表；依赖内部整数序号（如 WHERE status = 2）极危险，顺序变更会导致语义错乱；JPA 需用 @Enumerated(EnumType.STRING) 避免 Data truncated 错误；最优替代是 TINYINT + 应用层枚举或 CHECK 约束。
MySQL 中不建议用 ENUM 存动态数据，核心不是它“存不了”，而是每次加个值都要 ALTER TABLE MODIFY ENUM，触发全表重建 + 逐行校验，锁表时间不可控。
ALTER TABLE MODIFY ENUM 会锁表多久？
哪怕只是在 ENUM('active', 'inactive') 后面加一个 'pending'，MySQL 也必须：
- 创建临时表
- 拷贝全部现有行（500 万行？那就拷 500 万次）
- 对每一行检查值是否仍在新枚举范围内（比如残留的 'archived' 就会被截断报错）
- 若字段有默认值或允许 NULL，还要额外填充逻辑
- 最后重命名、清理临时表
整个过程全程持有写锁，应用写入阻塞，订单/支付类服务可能直接超时雪崩。
为什么用数字索引（如 WHERE status = 2）特别危险？
ENUM 内部按定义顺序存为整数：'draft'→1、'published'→2。但业务代码若依赖这个隐式序号：
- 后续改成 ENUM('draft','reviewing','published')，原 status = 2 就从 'published' 变成 'reviewing'
- PHP/Python 等弱类型语言中，INSERT ... VALUES(2) 和 VALUES('published') 行为完全不同
- ORM 如 Hibernate 配置 @Enumerated(EnumType.ORDINAL)，也会因顺序变更导致数据语义错位
Java/JPA 场景下 Data truncated for column 'xxx' at row 1 怎么修？
这是最常见但最容易误判的错误：JPA 默认用序号（0,1,2...）写入 ENUM 字段，而 MySQL 的 ENUM('RED','GREEN','BLUE') 底层只认字符串或从 1 开始的整数索引，0 是非法值。
正确做法是显式声明字符串持久化：
- 在实体字段上加 @Enumerated(EnumType.STRING)
- 确保数据库建表语句中 color ENUM('RED','GREEN','BLUE') 和 Java 枚举名完全一致（大小写敏感）
- 别用 int 字段硬映射枚举——那不如直接换 TINYINT + 应用层校验
替代方案里哪个最省事又可持续？
真要存状态类字段，优先选：
- TINYINT UNSIGNED 字段 + Java/Go 应用层枚举类（查库用数字，传参/展示用语义名）
- 动态管理需求强的，建 status_types 表，主键自增，存 code（如 'pending'）和多语言 label
- MySQL 8.0.16+ 可用 CHECK 约束：status VARCHAR(20) CHECK (status IN ('active','inactive','pending'))，改起来只需 ALTER TABLE DROP CHECK ADD CHECK，无锁无重建
真正难 debug 的从来不是语法，而是没人记得通知 DBA：那条凌晨三点跑的 ALTER 语句，会让所有写请求排队等锁。
