联合索引必须满足最左前缀匹配才能生效：WHERE a = ? ✅，a = ? AND b = ? ✅，b = ? ❌；覆盖索引要求SELECT和WHERE字段全部包含在索引中，实现免回表；ORDER BY须严格匹配索引前缀顺序，否则触发filesort。
联合索引和覆盖索引不是“加了就快”的开关，而是需要按查询模式精准设计的结构。真正把复杂查询优化到极致，关键在于让 MySQL 少走弯路——少扫描、少回表、少排序。
联合索引必须贴合 WHERE 条件的使用顺序
联合索引 (a, b, c) 不是三个字段随便堆一起，它的生效完全取决于 SQL 中 WHERE 的写法是否满足最左匹配：
- 有效使用：WHERE a = ? AND b = ? → 走前两列；WHERE a = ? AND b = ? AND c = ? → 三列全用上
- 半失效：WHERE a = ? AND c > ? → 只能用 a，b 和 c 都无法参与查找（b 被跳过，c 是范围）
- 完全失效：WHERE b = ? OR WHERE c = ? → 缺最左列 a，索引压根不被选中，直接全表扫描
Java 里用 MyBatis 或 JPA 写条件时，别只图代码顺手，要回头检查生成的 SQL 是否从左到右连续覆盖索引字段。比如租户系统高频查 tenant_id + status + created_at，索引就必须建为 (tenant_id, status, created_at)，不能因 created_at 时间戳区分度高就把它放第一位。
覆盖索引让查询“只扫索引，不碰数据行”
只要 SELECT 的所有字段 + WHERE 的过滤字段，全部落在同一个联合索引里，MySQL 就能跳过回表——这是性能跃升的关键一步。
立即学习“Java免费学习笔记（深入）”；
- 例如：SELECT id, name, email FROM user WHERE status = 'active' AND age > 25；若建索引 (status, age, id, name, email)，EXPLAIN 的 Extra 就会显示 Using index，说明整条查询在索引树里闭环完成
- 反例：只建 (status, age)，但 SELECT 还要 name 和 email → 必须回表查主键对应的数据行，IO 成倍增加
- 注意：覆盖索引不是越宽越好。字段太多会增大索引体积、拖慢写入，只把高频查询真用到的列放进去
ORDER BY 和分页必须复用索引前缀
带排序或 LIMIT OFFSET 的查询，性能对索引依赖极强。一旦 ORDER BY 字段顺序或方向与联合索引不一致，MySQL 就得额外做 filesort，数据量一上去就卡死。
- 索引是 (tenant_id, status, created_at)，那么 ORDER BY tenant_id, status 是高效的；但 ORDER BY status, created_at 就不行——顺序错，索引无法复用
- 分页场景如 LIMIT 20 OFFSET 10000，如果排序没走索引，MySQL 得先扫出 10020 行再丢掉前 10000，越往后越慢
- 小技巧：用游标分页（WHERE created_at > ? ORDER BY created_at LIMIT 20）替代 OFFSET，配合索引可彻底避开深度偏移问题
每条 SQL 都要用 EXPLAIN 验证，而不是靠猜
Java 应用里写了索引、SQL 看着也合理，不代表它真走了索引。必须抓出真实执行 SQL，手动跑 EXPLAIN 看结果：
- key 显示索引名 → 表示被选中
- key_len 对照字段长度（比如 INT 是 4，VARCHAR(50) 一般是 202）→ 判断实际用了几列
- Extra 出现 Using index → 覆盖索引生效；出现 Using filesort 或 Using temporary → 排序/分组没走索引，得优化
Spring Boot 开启 spring.jpa.show-sql=true + 日志级别调至 DEBUG，就能看到 JDBC 实际发出的 SQL，复制到 MySQL 客户端执行 EXPLAIN，这是唯一可信的验证方式。
