绝大多数情况下join查询慢该加索引，关键是为驱动表on字段（如orders.user_id）和被驱动表on字段（如users.id）分别建立匹配类型、无函数包裹的高效索引，并按where条件>join字段>order by字段顺序设计联合索引。

JOIN查询慢，是不是该加索引？

绝大多数情况下是。但关键不是“加不加”，而是“加在哪、加什么”。JOIN性能瓶颈通常卡在驱动表（左表）的连接字段未被索引，或被驱动表（右表）的ON条件字段缺乏高效索引。MySQL 8.0+ 的EXPLAIN会明确标出type=ALL或key=NULL——这就是没走索引的铁证。

实操建议：

• 先用EXPLAIN SELECT ... JOIN ...确认哪张表的哪个字段没走索引
• 驱动表的ON字段（如orders.user_id）必须有单列索引或作为联合索引最左前缀
• 被驱动表的ON字段（如users.id）必须有索引，且类型要匹配（比如INT对INT，不能VARCHAR连INT隐式转换）
• 避免在ON字段上用函数或表达式，例如ON UPPER(u.name) = UPPER(o.name)会让索引失效

联合索引该按什么顺序建？

顺序取决于查询中字段的使用模式，不是按表顺序，也不是按字母顺序。核心原则：**WHERE 条件优先级 > JOIN ON 字段 > SELECT 中的排序/分组字段**。

举例：常见查询是SELECT * FROM orders o JOIN users u ON o.user_id = u.id WHERE u.status = 'active' AND o.created_at > '2024-01-01' ORDER BY o.amount DESC。这时对orders表建联合索引应为：INDEX (user_id, created_at, amount)；对users表则是：INDEX (status, id)——因为id是JOIN的等值条件，且status在WHERE中高选择性。

容易踩的坑：

• INDEX (created_at, user_id)对上述查询无效：created_at范围查询后，user_id无法继续走索引（最左前缀中断）
• 把ORDER BY字段塞进联合索引末尾，仅当它能复用前面的索引扫描时才有意义；否则纯属冗余
• 联合索引字段数别超过 3–4 个，字段越宽（如VARCHAR(500)）、越多，索引体积越大，维护成本越高

LEFT JOIN 和 INNER JOIN 的索引策略一样吗？

不一样。本质区别在于驱动表是否固定、是否允许NULL扩展行。

INNER JOIN可由优化器选择驱动表，所以两张表的ON字段都强烈建议有索引；而LEFT JOIN强制左表为驱动表，右表是被驱动表——这意味着LEFT JOIN users u ON o.user_id = u.id中，orders.user_id必须有索引（驱动表连接字段），users.id也必须有索引（被驱动表主键/连接字段），但users其他字段上的WHERE条件（如u.deleted = 0）如果写在ON里，可能影响索引使用，写在WHERE里则会导致LEFT JOIN退化为INNER JOIN。

实操要点：

• LEFT JOIN的右表过滤条件，如需保留左表所有行，务必写进ON子句，而非WHERE
• 右表的ON字段索引必须覆盖等值匹配，不能只依赖主键索引而忽略WHERE中的额外约束
• 用EXPLAIN检查rows和filtered值：若filtered长期低于 10%，说明索引区分度差，考虑调整字段顺序或补充条件

什么时候联合索引反而拖慢写入？

每增删改一行，所有相关索引都要同步更新。联合索引越多、越宽，INSERT/UPDATE/DELETE就越慢——尤其是高频写入场景（如订单流水、日志表）。

判断依据：

• 单表写入QPS > 500，且已有3个以上二级索引，新增联合索引前务必压测
• 索引字段包含TEXT或长VARCHAR，即使只是前缀索引（如VARCHAR(255)建INDEX(name(10))），也会显著增加B+树分裂概率
• 用SHOW INDEX FROM table_name查Cardinality，若某字段基数（唯一值数量）/总行数

真正难的不是建索引，是权衡哪些查询必须快、哪些可以慢、哪些根本不用查——索引是业务访问模式的映射，不是越多越好。