OR、NOT、!=条件下索引覆盖仍可能生效，但前提是所有查询字段必须全部包含在索引中，且参与布尔判断的字段应置于联合索引最左侧以保障索引可被选用。
WHERE里有OR、NOT、!=时，索引覆盖还生效吗
不一定失效，但必须满足“所有查询字段都在索引中”这个硬条件。MySQL在遇到OR、!=、NOT IN等布尔表达式时，通常会放弃使用索引做范围扫描（type=range），退化为全表扫描（type=ALL）。但只要查询能走索引，并且索引包含全部SELECT字段，仍可能触发Using index。
常见错误现象是：明明建了(a, b, c)索引，SELECT a,b FROM t WHERE c != 1却没出现Using index——因为c不在索引最左位置，无法高效定位，优化器干脆不走索引。
- 优先把参与布尔判断的字段放在联合索引最左侧（哪怕它是
!=字段），例如WHERE status != 'draft'，索引应设计为(status, id, name) -
OR条件要小心：只有当每个OR分支都能独立命中同一索引时，才可能合并使用；否则优化器大概率放弃索引 - 用
EXPLAIN确认：重点看key列是否非空，以及Extra是否含Using index，而不是只盯type
多条件混合查询（AND+OR+函数）怎么设计覆盖索引
混合布尔逻辑下，索引设计本质是“保主干、舍边缘”。MySQL只对索引的最左前缀做高效过滤，后续字段只能用于覆盖或排序，不能参与条件筛选。
比如查询：SELECT id, name, created_at FROM orders WHERE (user_id = 100 OR product_id = 200) AND status = 'paid' ORDER BY created_at，这个OR让user_id和product_id无法共用一个索引做高效过滤，但你可以拆解目标：
- 如果
user_id = 100占95%流量，就建(user_id, status, created_at, id, name)——覆盖该路径全部字段 - 如果
product_id查询也高频，单独建(product_id, status, created_at, id, name)，避免强行塞进同一索引导致宽索引膨胀 - 绝对不要在索引里加
UPPER(name)这类函数字段——索引存的是原始值，函数调用必然导致失效
ORDER BY + 布尔条件 + LIMIT 的覆盖索引陷阱
这种组合最容易误判“已覆盖”，实际却悄悄回表。原因在于：即使SELECT字段全在索引里，若ORDER BY字段不在索引中，或顺序不匹配，MySQL仍需取出所有匹配行再内存排序，此时Using index不会出现。
典型错误是建了(a, b)索引，却执行SELECT a,b FROM t WHERE a > 1 ORDER BY b DESC LIMIT 10——看起来字段都齐了，但a > 1是范围查询，b在索引第二位，无法保证b有序，优化器必须回表取数据后排序。
- 确保
ORDER BY字段紧接在WHERE等值条件之后，例如(status, created_at, id, name)支持WHERE status = 'done' ORDER BY created_at - 范围条件（
>、<、BETWEEN）右侧的字段，仅可用于覆盖，不能用于排序或过滤 -
LIMIT本身不改变索引选择逻辑，但它放大低效排序的代价——10万行里取10条，却要先排序全部匹配行
EXPLAIN里看到Using index，但查询还是慢？
这说明索引覆盖成立，但其他环节拖了后腿。常见真实瓶颈包括：
- 索引本身太宽：比如把
TEXT字段或长VARCHAR塞进联合索引，导致B+树层级变深、缓存命中率下降 - WHERE条件区分度极低：如
gender != 'unknown'匹配99%行数，即使覆盖索引，也要扫描几乎整个索引树 - 并发高时索引页争用：覆盖索引减少IO，但不减少锁竞争；若大量写入同时发生，
idx_user_status可能成为热点 - MySQL版本差异：MySQL 8.0+对
!=和OR的ICP（索引下推）支持更好，老版本更倾向全表扫描
真正难处理的不是“能不能覆盖”，而是“值不值得为这个查询单独建索引”——尤其当布尔表达式来自动态拼接SQL时，索引容易变成维护负担而非性能杠杆。
