WHERE条件顺序几乎不影响索引使用，真正起作用的是最左前缀匹配、数据选择性及是否发生隐式转换或函数包裹；执行计划需重点看type、possible_keys、rows和Extra字段。
WHERE 条件顺序真的影响索引使用吗？
MySQL 和 PostgreSQL 等主流数据库里，WHERE 子句中条件的书写顺序 几乎不影响 优化器是否能用上索引。真正起作用的是列是否出现在索引的最左前缀中、数据选择性高低、以及是否有隐式类型转换。
常见错误现象：WHERE status = 'active' AND user_id = 123 写成 WHERE user_id = 123 AND status = 'active'，有人以为后者更快——其实只要 (user_id, status) 是联合索引，两种写法执行计划通常完全一致。
- 优化器会重排谓词顺序，按统计信息和索引结构决定执行路径
- 唯一例外是某些老版本 MySQL（5.6 之前）在极简查询中可能不重排，但已不是现实问题
- 如果你发现顺序变了导致索引失效，大概率是某一边发生了隐式转换或函数包裹，比如
WHERE DATE(created_at) = '2024-01-01'直接让索引失效，跟顺序无关
怎么看执行计划里索引到底有没有被用上？
别只盯着 key 字段是否非 NULL，重点看 type、possible_keys、rows 和 Extra 四个字段。
-
type是关键：出现ALL表示全表扫描；range或ref才算走了索引；index是索引全扫描，不一定高效 -
possible_keys列出所有可用索引，但实际只选一个；如果为空，说明没有索引覆盖 WHERE 条件 -
rows是优化器估算的扫描行数，数字越大越危险（注意：不是返回行数） -
Extra里出现Using where是正常；但Using filesort或Using temporary往往意味着排序/分组没走索引
示例（MySQL）：
EXPLAIN SELECT * FROM orders WHERE user_id = 123 AND status = 'paid';如果
key 显示 idx_user_status，type 是 ref，rows 是个位数，基本没问题。
联合索引最左前缀原则怎么实操验证？
不是“从左到右必须连续”，而是“匹配从最左列开始的连续列”。比如索引是 (a, b, c)：
- ✅
WHERE a = 1—— 走索引 - ✅
WHERE a = 1 AND b = 2—— 走索引 - ✅
WHERE a = 1 AND b = 2 AND c > 3—— 走索引（c 用范围，b 必须等值） - ❌
WHERE b = 2—— 不走索引（跳过 a） - ❌
WHERE a > 1 AND c = 3—— c 不会生效（a 是范围，中断前缀）
容易踩的坑：
- 在
IN后面跟大量值（如a IN (1,2,3,...1000)），部分版本可能退化为全索引扫描，rows会暴增 -
OR连接不同列（WHERE a = 1 OR b = 2）通常无法利用联合索引，除非每个分支都有独立索引
为什么加了索引，EXPLAIN 却显示没用？
索引存在 ≠ 查询一定用它。优化器可能主动放弃索引，常见原因：
- 表太小（比如只有几十行），走索引反而比全表扫描更慢
- 查询返回大量数据（如
WHERE status != 'cancelled'），优化器预估用索引要回表太多次，直接全表更省 - 索引列上有函数或表达式：
WHERE UPPER(name) = 'JOHN'、WHERE age + 1 = 30都会让索引失效 - 统计信息过期（尤其 ANALYZE TABLE 没跑过），优化器误判选择性，可通过
ANALYZE TABLE table_name更新
一个真实例子：某张 20 万行的订单表，加了 (status, created_at) 索引，但 WHERE status IN ('pending', 'processing') 仍走全表——因为这两个状态占了 95% 数据，优化器认为回表成本太高，不如扫一遍聚簇索引。
复杂点在于：同一 SQL，在不同数据分布下，执行计划可能完全不同。上线前一定要用接近生产的数据量做 EXPLAIN 验证，而不是只在空库或测试库里看。
