90%的多表JOIN查询慢源于执行路径错误：索引缺失（ON字段需有效复合索引且被实际使用）、驱动表选错（小表驱动大表，避免LEFT JOIN右表加WHERE）、中间结果集爆炸（慎用LEFT JOIN，优先INNER JOIN或拆分查询）。
多表 JOIN 查询慢，90% 的情况不是语法写错了，而是执行路径没走对——索引缺失、驱动表选错、中间结果集爆炸这三件事，比 JOIN 类型本身影响更大。
确保所有 ON 字段都有有效索引
没有索引的 JOIN 等于让数据库硬扫两张表再逐行比对，数据量一过十万，响应时间就指数级上升。重点不是“有没有索引”，而是“索引是否被真正用上”。
-
EXPLAIN中type列必须是ref、range或const，不能是ALL或index - 复合索引要按
ON条件中字段的出现顺序来建，比如JOIN t2 ON t1.a = t2.x AND t1.b = t2.y，t2 上应建(x, y)而非单列x - 外键列不等于有索引：MySQL 不会自动为外键字段建索引，必须显式执行
CREATE INDEX idx_user_id ON orders(user_id) - 注意隐式类型转换：如果
users.id是BIGINT，而orders.user_id是VARCHAR，即使加了索引也会失效
把大表当被驱动表，小表当驱动表
MySQL 默认采用嵌套循环连接（Nested Loop Join），它会拿驱动表的每一行去匹配被驱动表。驱动表越小，循环次数越少，整体开销越低。优化器有时会选错，得靠 STRAIGHT_JOIN 或重写顺序干预。
- 用
SELECT COUNT(*)快速估算各表参与 JOIN 的实际行数，别只看总行数——WHERE 条件过滤后剩多少才关键 - 在 12 表关联场景中，优先让带强过滤条件（如
WHERE order_date > '2023-01-01'）的表做驱动表 - 避免在 LEFT JOIN 的右表上加 WHERE 条件：比如
LEFT JOIN coupons c ON o.id = c.order_id WHERE c.status = 'used'实际会转成 INNER JOIN，且可能让优化器误判驱动顺序 - 必要时加
STRAIGHT_JOIN强制顺序：SELECT STRAIGHT_JOIN ... FROM small_table s JOIN large_table l ON s.id = l.small_id
用 INNER JOIN 替代 LEFT JOIN 的前提是业务允许
很多慢查询的根源是用了 LEFT JOIN 却只关心匹配数据。LEFT JOIN 会保留左表全部记录，导致中间结果集膨胀、NULL 值参与后续计算、临时表溢出磁盘，这些开销远超 JOIN 本身。
- 检查 WHERE 条件是否已隐含 INNER 语义：比如
LEFT JOIN orders o ON u.id = o.user_id WHERE o.amount > 100，这条语句实际排除了所有无订单用户，等价于 INNER JOIN，但执行计划仍按 LEFT 处理 - 统计类查询（如“每个用户订单数”）用 LEFT JOIN 合理；明细类查询（如“近一周下单用户的收货地址”）应优先用 INNER JOIN
- 用
EXPLAIN FORMAT=JSON查看filtered字段：如果 LEFT JOIN 的右表filtered值极低（如 0.1），说明大量 NULL 行被生成又丢弃，是典型优化信号 - 替换后务必验证结果集行数是否变化，避免业务逻辑错误
拆分复杂 JOIN，交给应用层组装
12 表 JOIN 不是不能跑，而是不可维护、不可预测。一旦某张表数据突增或统计信息过期，执行计划可能瞬间退化。阿里规范禁三表以上 JOIN，不是拍脑袋，是踩过太多坑后的收敛策略。
- 把原始 SQL 拆成 2–3 个独立查询：一个查主表+核心关联表（如
orders + users + products），另一个查扩展维度（如logistics + invoices），应用层用主键 hash 关联 - 对高频访问的中间结果（如“近7天活跃用户ID列表”），可提前写入临时表或 Redis 缓存，避免每次重复 JOIN
- 注意事务一致性：拆分后若需强一致性，应用层要控制好查询时机，或改用
SELECT ... FOR UPDATE加锁 - 临时表不是万能解药：
CREATE TEMPORARY TABLE tmp AS SELECT ...会增加磁盘 I/O 和锁竞争，仅适用于中间结果集小（
最常被忽略的一点：JOIN 效率不只取决于 SQL 写法，还卡在 join_buffer_size 和 tmp_table_size 这两个参数上。默认值往往太小，导致本该内存完成的哈希连接被迫落盘，性能断崖下跌——调参前先用 SHOW STATUS LIKE 'Created_tmp%' 看是否频繁创建磁盘临时表。
