ENUM字段加索引并非无效，但常因基数误判、数据倾斜、统计陈旧及错误查询写法（如用数字而非字符串）导致索引失效；仅支持等值匹配，范围查询无效；推荐改用TINYINT+CHECK或字典表。
ENUM 字段加索引不是无效，但很容易“加了等于没加”——根本问题不在语法对错，而在 MySQL 优化器对 ENUM 基数（cardinality）的误判和查询写法的隐式陷阱。
为什么 EXPLAIN 显示 key=null，明明建了索引？
这是最常被忽略的信号：EXPLAIN 中 key 列为空、rows 高得离谱，说明优化器跳过了索引。原因通常是：
-
SHOW INDEX FROM table_name查到的Cardinality值远低于实际不同值数量（比如枚举定义了 5 个值，但统计显示只有 1 或 2） - 表数据分布严重倾斜（例如 99% 是
'active'，其余值极少），优化器判定“选择性太低”，直接放弃索引 - 没运行过
ANALYZE TABLE table_name，统计信息陈旧，优化器靠猜
查询必须用字符串字面量，不能用数字
ENUM 的语义契约是：对外只认字符串，内部整数只是存储实现。一旦写错，索引立刻失效且逻辑出错：
- ✅ 正确：
WHERE status = 'active'—— 走索引，语义清晰 - ❌ 错误：
WHERE status = 2—— 不走索引，且当枚举定义顺序变动时结果不可控 - ⚠️ 危险：
WHERE status + 0 = 2—— 强制转为数字比较，绕过索引，纯属反模式
IN 可用，BETWEEN 和 > 基本无效
ENUM 索引只支持等值匹配及其有限扩展，B+ 树无法支撑真正的范围扫描：
-
WHERE status IN ('active', 'archived')→ 有效，等价于多个=查询 -
ORDER BY status→ 可避免 filesort，但排序结果按定义顺序（'inactive','active','archived'），不是字典序 -
WHERE status > 'active'→ 不走索引；MySQL 实际按字符串比较，且无法利用索引结构
比 ENUM 更可控的替代方案
当状态需要频繁查询、排序、扩展，或 DBA 需要稳定执行计划时，ENUM 就成了黑盒。更推荐：
- 用
TINYINT UNSIGNED存状态码（如1=active, 2=inactive），配合CHECK约束（MySQL 8.0.16+）保证取值范围 - 在该字段上建普通 B+ 树索引，基数准确、范围查询可用、排序行为可预期
- 若需强语义关联，单独建字典表（如
status_dict(id, code, name)），应用层或 JOIN 关联
真正容易被忽略的是：ALTER TABLE 修改 ENUM 枚举值列表会锁表，大表上线即阻塞写入——这不是性能问题，是发布风险。
