ENUM字段加索引有效但常被优化器跳过，主因是基数误判、数据倾斜、统计陈旧及错误查询写法（如用数字而非字符串）；仅支持等值匹配，范围查询无效；推荐改用TINYINT+CHECK或字典表。
ENUM字段加索引不是无效，但常等于白加——优化器大概率跳过它，且无法支持范围查询。
EXPLAIN 显示 key=null 却明明建了索引？
这是最直接的信号：索引存在，但 MySQL 优化器拒绝使用。常见原因包括：
-
SHOW INDEX FROM table_name查出的Cardinality值严重偏低（比如枚举定义了 5 个值，统计却显示 1 或 2） - 实际数据极度倾斜（例如 98% 的记录是
'active'），优化器判定“选择性太低”，直接放弃索引 - 没运行过
ANALYZE TABLE table_name，统计信息陈旧，优化器靠猜测做决策
WHERE status = 2 不走索引，且语义错误
ENUM 的语义契约是：对外只认字符串，内部整数只是存储实现。写数字字面量会同时破坏索引和逻辑：
- ✅ 正确：
WHERE status = 'active'—— 走索引，语义清晰 - ❌ 错误：
WHERE status = 2—— 不走索引；且当枚举定义顺序变动（如新增值插在中间），结果不可控 - ⚠️ 危险：
WHERE status + 0 = 2—— 强制类型转换，绕过索引，纯属反模式
IN 可用，BETWEEN 和 > 基本无效
ENUM 索引本质仍是 B+ 树，但 MySQL 不支持对其做真正的范围扫描：
-
WHERE status IN ('active', 'archived')→ 可命中索引（多个等值查找） -
ORDER BY status→ 可避免filesort，但排序顺序严格按枚举定义顺序（'inactive','active','archived'），不是字典序 -
WHERE status > 'active'→ 不走索引；MySQL 实际按字符串比较，且无法利用 B+ 树结构
真正容易被忽略的代价：ALTER TABLE 修改 ENUM 会锁表
这不是性能问题，而是发布风险。大表执行 ALTER TABLE ... MODIFY COLUMN status ENUM(...) 会全程锁表，阻塞所有写入操作。相比而言，TINYINT 字段只需加 CHECK 约束（MySQL 8.0.16+），扩展新状态无需 DDL，更可控。
