必须加索引的字段包括：被驱动表的join条件字段、驱动表的where过滤字段、order by/limit涉及且未被覆盖索引包含的字段；联合索引顺序应为等值字段在前、连接字段紧贴、范围字段在后。
联合查询中哪些字段必须加索引
联合查询（JOIN）性能差，90% 是因为驱动表和被驱动表的连接字段没索引，或者索引失效。mysql 用 Nested Loop Join，驱动表每行都要去被驱动表查匹配行——如果被驱动表的 ON 字段没索引，就会全表扫描。
必须加索引的字段包括：
-
JOIN条件中的被驱动表字段（如t2.user_id） - 驱动表中用于过滤的字段（如
WHERE t1.status = 'active'的t1.status） -
ORDER BY和LIMIT涉及的字段，若出现在最终结果集里且未被覆盖索引包含
注意：ON 中多个字段要建联合索引，顺序按「驱动表过滤条件 → 被驱动表连接字段」排列，例如：ALTER table orders ADD INDEX idx_user_status (user_id, status);
EXPLAIN 看懂 JOIN 执行顺序是否合理
EXPLAIN 的 type 列是关键：ALL 或 index 表示全表/全索引扫描，危险；ref、eq_ref、const 才算走索引。同时看 rows 值——它反映 MySQL 预估的单次查找行数，不是总行数。
常见误判点：
- 驱动表选错了：
EXPLAIN第一行是驱动表，但 MySQL 可能因统计信息不准选错。可用STRAIGHT_JOIN强制顺序 -
Extra出现using join buffer (Block Nested Loop)：说明被驱动表没走索引，正在回表硬扛 -
key为NULL：该表完全没用上索引，哪怕你建了
示例：EXPLAIN select * FROM users u JOIN orders o ON u.id = o.user_id WHERE u.created_at > '2023-01-01'; —— 先确认 users 表是否走了 created_at 索引，再确认 orders 表是否走了 user_id 索引。
联合索引字段顺序怎么排才不浪费
联合索引不是字段堆砌，顺序直接影响能否命中。核心原则：**等值查询字段在前，范围查询字段在后，连接字段紧贴等值字段**。
比如三表关联：users → orders → order_items，常用条件是 u.status = 'active' AND o.created_at > '2024-01-01' AND oi.item_type = 'book'，那么：
-
orders表索引应为(user_id, status, created_at)：先用user_id匹配外键，再用status过滤，最后created_at做范围（不能放最前） -
order_items表索引应为(order_id, item_type)：order_id是连接字段，必须第一；item_type是等值过滤，放第二
反例：(created_at, user_id) 对 WHERE created_at > ? AND user_id = ? 只能用上 created_at，user_id 失效。
小表驱动大表真的总是最优吗
“小表驱动大表”是经验法则，但 MySQL 8.0+ 的 CBO（基于成本优化器）会综合行数、索引选择性、IO 成本估算，不一定听你的。真正要干预的场景是：
- 统计信息过期：
ANALYZE TABLE没跑过，导致优化器误判表大小 - 大表有高选择性索引，小表反而没索引：这时让大表当驱动表 + 走索引，比小表全表扫更优
- 使用
IN子查询替代JOIN：有时SELECT ... WHERE id IN (SELECT user_id FROM orders WHERE ...)比JOIN更快，尤其子查询结果集小且有索引
验证方式：对比 EXPLAIN format=json 中的 cost_info 字段，看优化器自己算出的成本值。别只信“小表驱动”这四个字。
多表 JOIN 最容易被忽略的是索引覆盖和 NULL 值陷阱——LEFT JOIN 后字段为 NULL，却还在 WHERE 里写 o.status = 'paid'，直接把 LEFT 变成 INNER，还可能让索引失效。这类逻辑错误比索引没建更难排查。