联合索引需严格匹配查询顺序：等值字段按筛选性或出现频率从左到右排列，范围字段必须置最右；order by/group by须与索引顺序完全一致；覆盖索引仅包含必要字段，避免冗余。
等值查询用联合索引，但字段顺序必须匹配 WHERE 条件顺序
MySQL 的 WHERE a = ? AND b = ? 能走 INDEX(a, b)，但换成 INDEX(b, a) 就只能用上第一个字段 b，第二个字段 a 会失效。这是因为 B+ 树索引按左前缀顺序组织，只有最左字段命中后，后续字段才能被用于过滤或排序。
常见错误是把高频等值字段放在后面，比如用户表常查 status = 1 AND category_id = 5，却建了 INDEX(category_id, status)——这样 status 实际无法参与索引查找。
- 优先把筛选性高（低重复率）的字段放前面，比如
user_id比status更适合放左首 - 如果多个字段筛选性接近，把更常单独出现在 WHERE 中的字段放前，比如
tenant_id几乎总出现，就该置顶 - 避免在联合索引里包含不必要的字段，尤其是大字段（如
TEXT）或更新频繁的字段
范围查询字段必须放在联合索引最右，且之后字段全部失效
WHERE a = ? AND b > ? AND c = ? 这类混合条件中，b > ? 是范围查询，它后面的 c 字段即使加了等值条件，也无法利用索引做查找——MySQL 在遇到第一个范围条件（>、、<code>BETWEEN、LIKE 'abc%'）后，就停止向下使用索引字段。
所以 INDEX(a, b, c) 可以支持 a = ? AND b > ?，但不支持 a = ? AND b > ? AND c = ? 的索引查找（c 不参与查找，仅可能用于覆盖索引返回）。
- 把范围字段放到联合索引末尾，例如
INDEX(user_id, created_at)适合user_id = ? AND created_at > ? - 如果业务同时需要
created_at BETWEEN ? AND ?和status = ?，不要强行塞进一个索引，考虑拆成两个单列索引（MySQL 5.6+ 支持 Index Merge，但效果不稳定，慎用） -
IN是例外：它被视为多个等值，不会截断索引，WHERE a = ? AND b IN (?, ?, ?) AND c = ?中c仍可走索引
ORDER BY 和 GROUP BY 必须和索引顺序严格一致，否则触发 filesort
当 SELECT * FROM t WHERE a = ? ORDER BY b, c 时，只有 INDEX(a, b, c) 才能避免 filesort；如果建的是 INDEX(a, c, b)，哪怕所有字段都在索引里，MySQL 仍要额外排序。
原因在于：B+ 树叶子节点数据天然按索引定义顺序物理存储，只有完全匹配索引顺序的 ORDER BY 才能直接遍历获取有序结果。
- 升序（ASC）是默认行为，显式写
ORDER BY b ASC, c ASC和索引(b, c)匹配；但ORDER BY b DESC, c ASC就无法复用INDEX(b, c)（MySQL 8.0+ 开始支持混合方向索引，但需显式声明） -
GROUP BY同理，本质也要求有序输入，否则触发临时表 + 排序 - 如果查询中既有
WHERE又有ORDER BY，优先保证WHERE的等值/范围字段前置，再追加ORDER BY字段——顺序不能颠倒
覆盖索引能跳过聚簇索引回表，但别为了覆盖强行加冗余字段
当 SELECT a, b, c FROM t WHERE a = ?，若存在 INDEX(a, b, c)，MySQL 可直接从二级索引叶子节点取到全部字段，无需回主键索引查整行数据（即避免“回表”），这就是覆盖索引。
但它不是万能优化：索引本身要占磁盘和内存，字段越多，B+ 树层级越深、插入越慢、缓冲池压力越大。
- 只把真正高频查询中
SELECT列和WHERE列一起放进联合索引，不要把content TEXT或avatar_url这类大字段加进去 - 注意
SELECT *几乎不可能被覆盖，除非你建了个包含所有列的索引（绝对不可取） - 用
EXPLAIN看Extra列是否含Using index，这是覆盖索引生效的唯一可靠信号
索引设计没有银弹，关键在看清每条查询的 WHERE 字段组合、范围类型、ORDER BY 和 SELECT 列——然后让索引结构严格对齐这些访问模式。最容易被忽略的是：同一个字段在不同查询中角色可能不同（有时是等值，有时是范围，有时是排序），这时往往需要多个索引分别支撑，而不是硬凑一个“全能索引”。
