调优前必须先用EXPLAIN查看执行计划是否走索引，避免蒙眼优化；复杂关联查询常见陷阱包括字段类型不一致、隐式转换、索引列被函数包裹，导致key为NULL、type降级为ALL或index。
EXPLAIN 之前先看执行计划是否走索引
不跑 EXPLAIN 就直接改 SQL，等于蒙眼调优。复杂关联查询最常踩的坑是：你以为 ON 条件用了索引，其实没用上——比如字段类型不一致（INT 对 VARCHAR）、隐式类型转换、或者索引列被函数包裹（WHERE DATE(create_time) = '2024-01-01'）。这些都会让 key 列显示 NULL，type 落到 ALL 或 index。
实操建议：
- 对每个
JOIN的ON字段、WHERE过滤字段、ORDER BY字段，单独查一遍SHOW INDEX FROM table_name，确认索引存在且列顺序合理 - 检查字段类型是否完全一致，尤其注意
tinyint(1)和boolean在某些 ORM 中会被映射为字符串 - 避免在索引列上做运算或函数调用；如需按日期查，用
create_time >= '2024-01-01' AND create_time 替代 <code>DATE(create_time) = ...
LEFT JOIN 时别让子查询当被驱动表
MySQL 执行 LEFT JOIN 时，左侧是驱动表，右侧是被驱动表——而子查询（派生表）一旦出现在 FROM 子句里，就成了“虚表”，没法建索引，优化器只能全表扫描匹配。这是性能断崖的高发场景。
常见错误写法：SELECT * FROM orders o LEFT JOIN (SELECT user_id, COUNT(*) c FROM logs GROUP BY user_id) l ON o.user_id = l.user_id。这里 l 是被驱动表，但它是子查询结果，无索引可言。
实操建议：
- 把子查询提前物化成临时表，并在关键字段（如
user_id）上加索引：CREATE TEMPORARY TABLE tmp_logs AS SELECT user_id, COUNT(*) c FROM logs GROUP BY user_id; ALTER TABLE tmp_logs ADD INDEX idx_user_id(user_id); - 更优解是重写为
INNER JOIN+GROUP BY后聚合，或用LATERAL（MySQL 8.0.14+）替代派生表 - 如果必须用
LEFT JOIN，确保右侧是实体表，且ON字段有索引；宁可多查一次主表，也别让子查询坐右边
INNER JOIN 的驱动表不是你写的顺序决定的
INNER JOIN 的驱动表由优化器选，它看的是表大小、索引成本、统计信息——不是你 FROM a JOIN b 就一定先扫 a。但如果两张表都有索引，优化器通常会选小结果集当驱动表；如果只有一张表有索引，它会强制让有索引的那张当被驱动表（因为驱动表无论如何都要全扫）。
这意味着：你写 SELECT * FROM big_table b JOIN small_table s ON b.id = s.big_id，优化器可能反着来，用 small_table 驱动 big_table，只要 big_table.big_id 有索引。
实操建议：
- 用
EXPLAIN看table列顺序和rows值，确认实际驱动表是否合理；若不合理，可用STRAIGHT_JOIN强制顺序（但要配合FORCE INDEX使用） - 确保所有
JOIN字段类型严格一致、长度匹配（比如VARCHAR(50)对VARCHAR(100)可能触发隐式截断） - 大表关联前先用
WHERE过滤缩小结果集，比在JOIN后再WHERE更有效——前者减少驱动表行数，后者只是筛最终结果
覆盖索引能绕过回表，但字段顺序不能错
当查询的所有字段都包含在某个复合索引中，MySQL 就不用回到聚簇索引取数据，这叫“覆盖索引”。对关联查询特别有用——比如 SELECT u.name, u.email FROM users u JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'，如果在 orders 上建 INDEX idx_status_user(status, user_id)，再在 users 上建 INDEX idx_id_name_email(id, name, email)，就能避免回表。
但复合索引字段顺序错了就失效：比如 INDEX (user_id, status) 支持 WHERE user_id = ? AND status = ?，但不支持 WHERE status = ? 单独过滤。
实操建议：
- 联合索引按“过滤字段 + 关联字段 + 查询字段”排序；高频等值条件放最左，范围查询（如
BETWEEN、>）放最后 - 用
EXPLAIN的Extra列验证是否用了覆盖索引：出现Using index表示成功，Using where; Using index是部分覆盖，Using filesort或Using temporary说明还有瓶颈 - 别为了覆盖索引把大字段（
TEXT、BLOB）塞进索引——索引页会迅速膨胀，反而拖慢整体性能
真正卡住性能的，往往不是语法多复杂，而是索引字段类型不一致、子查询坐错位置、或者以为写了 JOIN 就自动优化了——这些细节在 EXPLAIN 里藏得浅，但改起来要动筋骨。
