联合索引遵循最左前缀原则，因b+树仅能从最左列开始连续匹配；跳过最左列（如where created_at > '2026-01-01'）导致全表扫描，等值字段须置最左以高效定位数据块，范围查询则中断右侧字段的索引下推能力。
等值字段必须放最左，因为B+树只能从左连续匹配
MySQL联合索引底层是B+树，节点按索引字段顺序逐层排序。查询时，优化器必须从最左列开始定位数据块——跳过它，就等于找不到树的根路径。比如索引 (status, created_at)，WHERE created_at > '2026-01-01' 无法定位到任何分支起点，只能全表扫描。
常见错误现象：
-
WHERE status = 1 AND created_at > '2026-01-01'能用上整个索引（status精确定位，created_at范围扫描） -
WHERE created_at > '2026-01-01' AND status = 1只能用上created_at，status变成回表后过滤，索引效率断崖下跌 -
WHERE user_id = 1001 AND status >= 1 AND create_time = '2026-09-01'中status >= 1是范围，导致create_time完全不参与索引查找
范围字段一出现，右侧所有字段就“失效”了
不是说它们没用，而是不能再用于缩小扫描范围。B+树在遇到第一个范围条件后，就停止向下精确匹配，后续字段只可能用于排序或覆盖索引（如果SELECT里只查它们），但不会减少IO扫描量。
实操建议：
- 一个联合索引里最多只保留一个范围字段，且必须放在所有等值字段之后
- 像
IN这种操作在 MySQL 8.0.24+ 可以和范围共存（如(user_id IN (1,2), created_at > '2026-01-01')），但老版本仍会截断，别依赖 -
LIKE 'abc%'属于范围行为，不能插在等值字段中间；LIKE '%abc'则完全不走索引
高频等值字段放最左，不只是为了“能用”，更是为了“少扫”
区分度高的字段（如 user_id）放最左，能让B+树第一层就筛掉大量无效分支；而低区分度字段（如 is_deleted）放最左，会导致树顶层节点极多，实际效果接近全表扫描。
验证方式很直接：
- 用
SHOW INDEX FROM table_name查看Cardinality，粗估区分度：COUNT(DISTINCT col) / COUNT(*) - 用
EXPLAIN看key_len：值越小，说明用到的索引列越少；Extra出现Using filesort或Using where也常意味着索引没被充分利用 - 不要相信SQL写法顺序——优化器会重排WHERE，但前提是**最左列必须存在**
ORDER BY 和 GROUP BY 字段必须紧接等值字段，且方向一致
如果索引是 (tenant_id, user_id, created_at)，那 ORDER BY tenant_id, user_id 可免排序；但 ORDER BY user_id, created_at 就会触发 Using filesort，因为跳过了最左的 tenant_id。
更隐蔽的问题：
- 范围字段会中断排序能力。索引
(user_id, created_at)对WHERE user_id = 123 ORDER BY created_at DESC有效；但换成WHERE user_id > 123 ORDER BY created_at，created_at就无法保证有序了 - 升序/降序必须和索引定义一致。MySQL 8.0+ 支持混合方向索引，但多数业务仍用默认ASC，别在没确认版本和需求时乱加
DESC
EXPLAIN 的 key_len 和 rows 才是最诚实的答案。
