SELECT * 在 JOIN 时让覆盖索引失效，因为其强制回表查询非索引列，破坏“无需回表”前提；覆盖索引生效需 SELECT 和 WHERE/JON 所有字段均落在同一联合索引中。
为什么 SELECT * 在 JOIN 时会让覆盖索引失效
因为 SELECT * 强制数据库回表——即使 WHERE 和 JOIN 条件列都命中了索引，只要查询结果里包含非索引列（比如 users.address），MySQL 就必须拿着索引里的主键去聚簇索引里再查一遍。这直接废掉覆盖索引的“不用回表”优势。
- 覆盖索引生效前提是：
SELECT的所有字段 +JOIN/WHERE用到的字段，全部落在同一个联合索引里 -
EXPLAIN中看到type=ref或range是好信号，但若Extra列出现Using where; Using index; Using join buffer，说明索引被用了，但没完全覆盖；如果出现Using where; Using index condition; Using temporary，基本已回表 - 复合索引顺序很重要：
(a, b, c)能覆盖SELECT a,b WHERE a=1 AND b>5，但不能覆盖SELECT b,c WHERE c=1
怎么写 JOIN 查询才能让覆盖索引真正起效
核心就一条：只查真正需要的字段，且这些字段要能被已有索引“一网打尽”。不是加个索引就行，是字段、顺序、类型都要对得上。
- 先用
EXPLAIN FORMAT=TREE看执行计划，确认filtered高、rows少、Extra里有Using index且没有Using filesort或Using temporary - 对
orders JOIN users这类常见场景，如果只查orders.id, orders.status, users.name，就在orders上建(status, id)，在users上建(id, name)—— 注意JOIN条件列（如orders.user_id）必须是索引最左前缀，否则无法驱动索引扫描 - 避免在
SELECT里用函数或表达式：SELECT UPPER(name)或SELECT created_at + INTERVAL 1 DAY都会导致索引失效
LEFT JOIN 时 NULL 字段会破坏覆盖索引吗
不会直接破坏，但会影响优化器判断。当右表无匹配行时，LEFT JOIN 返回 NULL，但索引本身不存 NULL（除非显式允许），所以关键不在 NULL 值，而在你查的字段是否仍在索引中。
- 如果
SELECT包含右表字段（如users.email），而该字段不在索引里，照样回表——哪怕实际值全是 NULL - 更隐蔽的坑：
ON条件里用了函数，比如ON u.id = CAST(o.user_id AS SIGNED)，会导致users.id索引无法使用，整个右表扫描变全表 - 用
IS NULL做过滤时，确保对应列有允许 NULL 的索引，否则可能走不到索引（尤其在旧版本 MySQL 中）
哪些 JOIN 场景根本没法靠覆盖索引优化
不是所有 JOIN 都适合覆盖索引，有些结构注定要 IO。别硬套，先看瓶颈在哪。
- 涉及大文本字段（
TEXT,MEDIUMTEXT）或大二进制字段（BLOB）：这类字段不进索引，只要 SELECT 里有它们，覆盖索引自动失效 - 多层嵌套 JOIN（如 A JOIN B JOIN C JOIN D）：即使每张表都有完美索引，优化器也可能选错驱动表顺序，导致中间结果集膨胀，最后一步无论如何都得回表
- 使用了
GROUP BY+HAVING且分组字段未索引：这时即使 SELECT 字段全在索引里，MySQL 仍可能先取全量再聚合，覆盖索引形同虚设
覆盖索引不是银弹，它只对“小字段+确定性访问路径”的 JOIN 友好。一旦涉及排序、分组、全文检索或任意一方数据量不可控，就得换思路——比如提前物化中间结果，或者把 JOIN 拆成应用层多次查询。
