mysql中where多字段and查询需按最左前缀原则建索引：等值字段（=、in）放前，至多一个范围字段（>、between、like 'abc%'）放末尾，order by字段可追加索引末尾以避免排序；or条件优先改写为union，in视为等值不影响索引；explain需重点观察type、rows和extra字段验证实际索引使用效果。
WHERE 中多个字段同时查，索引怎么建才生效
MySQL 的 WHERE 条件里用 AND 连多个字段时，只有按「最左前缀」顺序命中索引列，才能走索引。比如查 WHERE status = ? AND category = ? AND created_at > ?，但只给 (category, status) 建索引，status 就用不上——它不在索引最左边。
- 索引列顺序必须覆盖查询中「连续且从左开始」的条件字段
- 等值查询（
=、IN）字段放前面，范围查询（>、BETWEEN、LIKE 'abc%'）放后面，且只能有一个范围字段在末尾 - 如果还有
ORDER BY或GROUP BY，尽量把排序字段也塞进索引尾巴，避免额外排序
LIKE 模糊搜索还能用组合索引吗
能，但仅限前缀匹配：LIKE 'abc%' 可走索引；LIKE '%abc' 或 LIKE '%abc%' 一定不走，无论索引怎么建。
- 如果查询是
WHERE name LIKE 'John%' AND dept = 'tech'，索引应为(dept, name)或(name, dept)，但前者更优——因为dept是等值，name是范围，符合“等值+范围”结构 - 别指望
fulltext或LIKE配合组合索引解决全文模糊，那是FULLTEXT索引或ES的事 -
COLLATION要和查询一致，比如字段是utf8mb4_0900_as_cs，但查询用默认校对规则，可能导致索引失效
有 OR 条件时组合索引还管用吗
基本不管用。WHERE a = 1 OR b = 2 即使 a 和 b 各自都有单列索引，优化器大概率会放弃索引走全表扫描——MySQL 对 OR 的索引合并（index merge）支持弱，且代价高。
- 优先改写成
UNION：两个独立查询各自走索引再合并结果 - 如果必须用
OR，且字段都在同一张表，可尝试建覆盖全部 OR 字段的组合索引，但仅当所有分支都是等值时才可能触发 index merge union，不可依赖 -
IN不是OR：WHERE status IN ('a','b')算等值查询，不影响组合索引使用
EXPLAIN 看不出索引是否真生效？重点看这几个字段
EXPLAIN 输出里光看 key 显示了索引名，不代表真正高效；关键得盯 rows、type 和 Extra。
-
type是range或ref才算合理；ALL或index说明扫了太多行 -
rows值远大于实际命中的记录数？说明索引选择性差，或者条件没走对索引路径 -
Extra出现Using filesort或Using temporary，说明排序/分组没利用索引，得检查索引是否包含对应字段 - 执行
EXPLAIN FORMAT=JSON能看到used_key_parts，明确告诉你索引里哪几列被实际用了
组合索引不是堆字段越多越好，每多一列就增加 B+ 树节点大小、降低缓存效率；真正卡住性能的，往往是没意识到「等值字段顺序」和「范围字段位置」这两个硬约束。
