覆盖索引能否生效取决于SQL写法与索引设计是否匹配，关键看EXPLAIN中Extra列：Using index或Using where; Using index表示真正覆盖，其余多为回表；需避免SELECT *、函数操作、NULL判断等导致失效的写法。
Java 本身不控制是否回表，真正起作用的是你写的 SQL 和数据库里建的索引。只要 SQL 查询能命中覆盖索引，MySQL 就自动跳过回表；Java 只负责把这条 SQL 发出去，所以关键在写对 SQL、建对索引、验对执行计划。
看懂 EXPLAIN 是唯一验证方式
别凭感觉，每次优化前必须加 EXPLAIN 看执行计划，只盯 Extra 列：
- Using index ✅：真覆盖，所有字段都从索引叶子节点读出，没回表
- Using where; Using index ✅：也覆盖，同时用了索引下推和覆盖
- Using index condition ❌：只做了索引下推，SELECT 字段仍要回表
- 空值、Using where、Using filesort ❌：大概率回表了
SQL 写法必须配合索引结构
Java 拼 SQL 时稍不注意，覆盖就失效：
- 别写 SELECT *——二级索引不含所有列，必然回表
- WHERE 条件顺序要和联合索引最左前缀一致，比如索引是
(user_id, status, created_at)，就写WHERE user_id = ? AND status = ?，别倒过来 - ORDER BY 字段必须包含在索引中，且方向尽量匹配（如
ORDER BY created_at DESC，索引末尾也声明created_at DESC） - 避免对索引字段用函数或隐式转换，比如
WHERE DATE(create_time) = '2025-01-01'或mobile = 13812345678（mobile 是 VARCHAR）
设计联合索引要按访问模式排字段
不是堆字段，而是分层安排：
立即学习“Java免费学习笔记（深入）”；
-
等值条件字段放最左：如
user_id = ?、status IN (?, ?) -
范围条件放中间：如
created_at > ?，它右边的字段只能用于覆盖，不能用于查找 -
SELECT 和排序字段补在最后：如查
id, title, status，就把它们加在索引末尾；主键id不用重复建，InnoDB 自动带
示例：查 SELECT id, title, status FROM article WHERE category_id = ? ORDER BY create_time DESC，建索引：INDEX idx_cat_time_title_status (category_id, create_time DESC, title, status)
这些情况会让覆盖“悄悄失效”
即使索引定义看起来全，也可能白搭：
- SELECT 中含 TEXT/BLOB 字段：这类字段不进索引页，覆盖直接失效
-
索引总长度超 3072 字节：长 VARCHAR 要加前缀，比如
email(100) - WHERE 字段允许 NULL 且写了 IS NULL：优化器可能弃用索引，务必用 EXPLAIN 验证
-
低区分度字段放最左：比如
status只有 3 个值，建(status, user_id)容易被跳过，应调换顺序
