MySQL联合索引能否生效及生效列数取决于SQL是否满足最左匹配原则：必须从索引最左列开始连续使用，跳过中间列或范围查询后右侧列失效；WHERE缺最左列则索引不生效；ORDER BY/GROUP BY也需满足最左前缀且方向一致。
Java 应用里调用 MySQL 多条件查询时，能否走联合索引、能走几列，不取决于 Java 代码怎么写 WHERE，而取决于 SQL 本身是否满足最左匹配原则——这是 MySQL 查询优化器的硬性规则，Java 只负责把合法 SQL 发过去。
联合索引字段顺序必须贴合高频查询模式
比如业务中 90% 的查询都是 WHERE tenant_id = ? AND status = ? AND created_at > ?，那就该建 INDEX(tenant_id, status, created_at)。不能因为 created_at 区分度高就把它放最左——缺了 tenant_id，整个索引就失效。Java 中拼 SQL 或写 MyBatis XML 时，要确保参数顺序与索引定义逻辑一致（哪怕优化器会重排，但设计时就得对齐）。
WHERE 条件必须从最左列开始连续覆盖
- 有效：`WHERE tenant_id = 1001 AND status = 'paid'` → 走前两列
-
有效：`WHERE tenant_id = 1001 AND status = 'paid' AND created_at BETWEEN '2026-07-01' AND '2026-07-20'` → 走前两列，
created_at仅用于范围过滤，不加速精确定位 -
无效：`WHERE status = 'paid' AND created_at > '2026-07-01'` → 缺
tenant_id，索引完全不走，全表扫描 -
半失效：`WHERE tenant_id = 1001 AND created_at > '2026-07-01'` → 只用上
tenant_id，status和created_at都无法参与索引查找
ORDER BY 和分页也得遵循最左前缀
如果查询带 ORDER BY tenant_id, status，且索引是 (tenant_id, status, created_at)，那排序可直接利用索引，避免 filesort。但如果写成 ORDER BY status, created_at，即使 WHERE 有 tenant_id，排序也无法复用索引——顺序不一致，MySQL 不会自动调整。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
分页场景如 LIMIT 20 OFFSET 1000 更依赖有序扫描，一旦 ORDER BY 不匹配索引前缀，性能会随偏移量增大急剧下降。
用 EXPLAIN 验证 Java 发出的 SQL 是否真走索引
在 Java 开发阶段，别只看「建了索引」就认为生效。要在 MySQL 客户端或通过 Spring Boot 的 spring.jpa.show-sql=true + 日志抓取真实执行 SQL，再手动跑 EXPLAIN：
- key 显示索引名 → 索引被选中
- key_len 对照字段长度（如 INT=4，VARCHAR(50)=202）→ 判断用了几列
-
Extra 出现
Using index表示覆盖索引；出现Using where; Using index是正常回表；若含Using filesort或Using temporary，说明排序/分组没走索引
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
