JOIN查询慢主因是复合索引设计不当：WHERE等值字段须置最左，范围字段（如>、BETWEEN）应放末尾；ON字段必须索引且类型严格匹配；避免函数包裹；ORDER BY和SELECT字段仅在可复用路径时加入索引；务必用EXPLAIN验证。
JOIN 查询慢，八成是因为索引没建对——不是“要不要建”，而是“建在哪、字段顺序怎么排、哪些字段根本不能塞进去”。
WHERE 条件字段必须放复合索引最左边
索引失效最常见的原因，就是把范围查询字段（比如 created_at > '2024-01-01'）放在了联合索引前面。一旦出现范围查询，后续字段就无法继续走索引。
- ✅ 正确顺序：
INDEX (status, user_id, created_at)——status是高选择性等值条件（如WHERE u.status = 'active'），user_id是JOIN字段，created_at是范围条件，它只起过滤作用，不参与索引跳转 - ❌ 错误顺序：
INDEX (created_at, user_id)——created_at范围扫描后，user_id完全失效，EXPLAIN里会看到type=range后面再无ref或eq_ref - 区分“等值”和“范围”：
=、IN、IS NULL属于等值；>、<、BETWEEN、LIKE 'abc%'属于范围
JOIN 的 ON 字段必须能被索引直接命中
ON 子句里的字段，尤其是被驱动表（右表）的连接键，必须有索引，且类型严格匹配——隐式转换会让索引彻底失效。
- 驱动表（左表）的
ON字段（如orders.user_id）要作为联合索引最左前缀，或单独建索引 - 被驱动表（右表）的
ON字段（如users.id）必须有索引，且要是主键或唯一索引优先；如果只是普通索引，确保类型一致（INT对INT，别用VARCHAR去连） - 避免函数包裹：
ON UPPER(u.name) = UPPER(o.name)→ 索引失效；应统一存储为小写，或加生成列索引 -
LEFT JOIN下，右表字段若写在WHERE里（如WHERE u.deleted = 0），会导致逻辑退化为INNER JOIN；真要过滤右表，得写进ON，但要注意这会影响 NULL 行保留逻辑
ORDER BY 和 SELECT 字段要不要塞进联合索引？
只有当排序字段能复用已有索引扫描路径时，才值得加；否则纯属膨胀索引体积、拖慢写入。
- ✅ 可加：
ORDER BY o.amount DESC且查询中已有WHERE o.user_id = ? AND o.created_at > ?→ 建INDEX (user_id, created_at, amount)，amount在末尾可避免文件排序（Using filesort消失） - ❌ 别加：
SELECT u.name, u.email FROM ... ORDER BY u.email，但u.email不在 WHERE 或 JOIN 条件里 → 单独建INDEX (email)更轻量，别硬塞进大联合索引 - 覆盖索引优先：如果
SELECT只查几个字段，比如SELECT name, email FROM users WHERE status = 1，直接建INDEX (status, name, email)，避免回表 - 字段数别超 3–4 个，尤其别把
VARCHAR(500)这种宽字段堆在前面
如何验证索引是否生效？
别猜，用 EXPLAIN 看真实执行计划——这是唯一可信依据。
- 关键看三列：
type（ALL是全表扫描，ref/eq_ref才算走索引）、key（实际用了哪个索引）、Extra（出现Using where; Using index是覆盖索引，Using filesort或Using temporary就得优化） - 对
LEFT JOIN，特别注意右表的type：如果是ALL或NULL，说明右表连接字段没索引 - 建完索引后跑
ANALYZE TABLE table_name，让优化器更新统计信息，否则可能仍按旧计划执行 - 测试数据量要接近生产规模；本地小表上
EXPLAIN看着好，上线大数据量照样崩
ON 字段，或者被范围查询拦腰截断的最左前缀。动手前先 EXPLAIN，改完再 EXPLAIN，中间别跳步。 
