ENUM字段加索引却更慢，是因为MySQL将其存为整数但优化器在非等值查询（如!=、>）或隐式转换时放弃索引，且值域小、重复高导致全表扫描成本更低。
ENUM 字段加了索引却更慢？不是索引没生效，而是 MySQL 对 ENUM 的底层存储和比较逻辑，让优化器在多数场景下主动放弃走索引。
ENUM 字段的索引本质是整数比较
ENUM 在 InnoDB 中物理存储的是 1~65535 的整数（对应枚举值序号），而非字符串本身。比如：
CREATE TABLE order_status (
id INT PRIMARY KEY,
status ENUM('pending', 'paid', 'shipped', 'cancelled')
);此时 'pending' 存为 1，'paid' 存为 2，依此类推。索引 B+ 树里存的也是这些整数。
但问题出在查询写法上：
- 如果你写
WHERE status = 'paid'，MySQL 会把字符串'paid'转成整数2，再走索引 → 能用上 - 如果你写
WHERE status IN ('paid', 'shipped')，也转成IN (2, 3)→ 能用上 - 但如果你写
WHERE status != 'pending'或WHERE status > 'paid'，MySQL 就没法直接映射成整数区间比较，尤其>/<在字符串语义和序号语义间存在歧义 → 优化器倾向全表扫描
更关键的是：ENUM 值域小、重复率高，优化器评估成本时发现：
- 全表扫描可能只需读几个数据页（因为行很紧凑）
- 走索引要先查二级索引树 + 回表取整行（如果
SELECT *）
→ 它算下来“全扫更快”，就直接跳过索引。
查询条件中混用字符串和数字引发隐式转换
ENUM 字段支持两种等价写法，但后果不同：
- ✅
WHERE status = 'paid'—— 类型匹配，转整数后走索引 - ❌
WHERE status = 2—— 看似是整数，但 MySQL 会把2当作 序号 还是 字符串字面量？不同版本行为不一致；某些情况下触发隐式转换逻辑，导致索引失效 - ⚠️
WHERE status = CAST(2 AS CHAR)—— 强制转字符串，破坏整数映射，索引失效
实际执行计划里常看到 key = NULL 或 type = ALL，就是这个原因。
联合索引中 ENUM 放在非最左位置等于白建
假设你建了联合索引 <code>INDEX idx_user_status (user_id, status)</code>：
-
WHERE user_id = 123 AND status = 'paid'→ 可用（最左前缀匹配） -
WHERE status = 'paid'→ 不可用，因为没提供user_id，B+ 树无法定位起始位置 -
WHERE status = 'paid' AND is_deleted = 0→ 即使is_deleted有索引，status单独出现也无法触发联合索引的前缀扫描
这点和普通字段一样，但 ENUM 更容易让人误以为“值少=好查”，忽略最左前缀约束。
真正影响性能的，往往不是“有没有索引”，而是你写的条件是否能让优化器信任这个索引比全表扫描更便宜。对 ENUM 来说，值越少、分布越均匀，优化器越可能放弃索引——这不是 bug，是它算出来的最优解。想强制走索引？FORCE INDEX 能压住一时，但掩盖了统计信息不准或查询模式不合理的问题。
