不需要，MySQL优化器会自动重排WHERE条件顺序以匹配索引最左前缀；但联合索引字段的物理顺序必须严格遵循查询模式，缺失最左字段或中间断开将导致右侧字段全部失效。
联合索引不是字段堆砌，而是按查询模式精准对齐——建错顺序，90%的WHERE条件压根不走索引。
WHERE条件顺序和联合索引字段顺序必须对齐吗？
不需要SQL里WHERE子句的字段顺序和索引定义一致，MySQL优化器会自动重排条件。但索引字段的物理顺序必须匹配“最左前缀”的实际使用模式。
-
INDEX (tenant_id, status, created_at)能支持WHERE tenant_id = ? AND status = ?，也能支持WHERE status = ? AND tenant_id = ?（优化器重排后仍命中前两列） - 但完全无法支持
WHERE status = ? AND created_at > ?——tenant_id缺失，最左字段断开，整个索引失效 - 如果业务中
tenant_id和status几乎总是一起出现，而created_at只在部分查询中用于范围过滤，那这个顺序就是合理的；反过来把created_at放最左，反而会让大量等值查询失效
范围查询（>、
不生效。范围查询是索引查找的“截止点”，右侧所有字段退出WHERE条件过滤，最多参与排序或覆盖（如果SELECT只查索引列）。
-
INDEX (a, b, c)+WHERE a = 1 AND b > 10 AND c = 2→ 只有a和b用于定位，c = 2被下推到引擎层做逐行过滤（ICP），不减少B+树搜索路径 - 想让
c也参与索引查找？要么调换顺序为(a, c, b)，要么确认b实际是IN(10, 11, 12)——MySQL会把它当等值处理，右侧字段继续生效 -
LIKE 'abc%'算等值前缀，能用索引；LIKE '%abc'或LIKE '%abc%'直接跳过整个索引
怎么验证联合索引到底有没有真正生效？
不能只看EXPLAIN里key非空，得盯死三个字段：key、key_len、Extra。
-
key为空 → 没走索引（检查WHERE是否漏掉最左字段、是否对索引列用了函数如YEAR(created_at)） -
key有值但rows接近全表行数 → 索引建了但没起效（常见于选择性差：比如status只有3个值，优化器可能直接放弃索引） -
key_len= 8（假设INT占4字节）→ 实际只用了前两个字段，第三个没命中（可据此反推索引使用深度） -
Extra里出现Using index才算真正覆盖；Using index condition表示用了ICP，仍有回表；Using where; Using index是常见误导项，它只说明WHERE用了索引，不代表覆盖
高频等值字段必须放最左，哪怕区分度低
别被“高区分度字段放前面更高效”的直觉带偏。联合索引首要目标是匹配查询模式，不是单列区分度最大化。
- 比如
user_id和tenant_id每次查询都带=，哪怕email唯一性更高，也不该抢第一位 - 常查
WHERE status = ? AND created_at > ?，但status只有3个值 → MySQL很可能跳过索引。这时必须补一个前置的高频率字段，比如tenant_id = ?，变成INDEX (tenant_id, status, created_at) -
ORDER BY字段要紧接等值条件之后，且方向一致（ASC/DESC需与索引定义一致），否则触发Using filesort
最容易被忽略的是：索引字段顺序一旦定下，就锁死了所有可能的WHERE组合路径。改一次顺序，往往要重新评估十几种查询模式——不是加个索引就完事，而是给查询画一张不可逆的导航地图。
