TINYINT比ENUM更优，因其排序直观、索引高效、演进灵活、错误暴露明确且语义清晰；ENUM存在排序非字典序、索引难优化、修改锁表、ORM映射不一、非法值静默转0等隐患。
因为 TINYINT 比 ENUM 更可控、更兼容、更易演进，且存储开销几乎相同。
ENUM 的 ORDER BY 和索引行为不直观
MySQL 对 ENUM 字段排序时，默认按「定义顺序」而非字典序或值语义排序。比如定义 ENUM('high', 'low', 'medium')，ORDER BY 会按 1→2→3（即 high→low→medium）排，而不是按字母或业务优先级。这容易引发前端分页、后台导出逻辑错乱。
更麻烦的是：ENUM 列无法直接用数字索引做范围查询（如 WHERE gender + 0 > 1），优化器很难利用索引；而 TINYINT 上的 WHERE status >= 2 能走索引，执行计划干净。
- ALTER TABLE 修改 ENUM 允许值列表会锁表（尤其在大表上阻塞写入）
- ORM（如 MyBatis、Django）对 ENUM 的映射不统一，有些生成字符串，有些生成整数，容易在联查或 DTO 转换时出错
- 备份/恢复或跨版本迁移时，ENUM 值顺序变化可能引发隐式转换异常
TINYINT(1) 不等于布尔类型，别被误导
很多人看到 TINYINT(1) 就以为是布尔型，其实括号里的 1 只是显示宽度（zerofill 场景才生效），和取值范围完全无关。它仍能存 0–255（UNSIGNED）或 −128–127（默认有符号）。
真正该用的是 TINYINT UNSIGNED，明确限定为非负小整数：
- 订单状态字段：定义为
status TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '0待支付,1已支付,2已发货,3已完成' - 避免用
TINYINT(1)—— 它既不校验输入，也不限制范围，纯属历史遗留显示习惯 - 应用层配合使用枚举类（Java 的
enum、Go 的iota、Python 的Enum）做双向映射，比靠数据库约束更可靠
ENUM 插入非法值时行为危险且不可控
当插入不在允许列表中的值时，MySQL 在严格模式下报错 Data truncated for column 'xxx' at row N；非严格模式下却静默转成空字符串（数值为 0），而这个 0 和你定义的合法值 '0' 或状态码 0 完全无法区分。
例如字段 grade ENUM('0','1','2')，插入 '3' 后查 grade + 0 得到 0，但你无法判断这是「用户填了非法值」还是「业务上真有 grade=0」。
-
TINYINT遇到超界值（如插入 300 到TINYINT UNSIGNED）会直接报错Out of range，问题暴露得早、明确 - 应用层可预校验（如 Spring Validation 注解、DTO 构造时抛异常），比依赖数据库兜底更主动
- 后续加新状态只需改应用代码+SQL
ALTER TABLE ... MODIFY COLUMN，不用动 ENUM 列表顺序
最常被忽略的一点：ENUM 的内部数字索引从 1 开始，但 0 和 NULL 是特殊保留位。这意味着你永远不能安全地把「未设置」和「第一个合法值」在数值层面区分开——而 TINYINT 可以明确定义 NULL 表示未设置、0 表示待处理，语义清晰无歧义。
