目录一、慢 JOIN SQL 的本质是什么二、最致命特征被驱动表 type ALL三、相关子查询DEPENDENT SUBQUERY四、Using join buffer索引 JOIN 失败的信号五、如何优化你有没有遇到过这种情况单表查询嗖嗖快一旦多表关联JOIN就卡成狗甚至直接超时这其实不是因为“数据太多”而是因为 JOIN 背后的执行路径被无限放大。结果就是系统资源被白白浪费查询时间呈指数级增长业务也跟着“躺平”。今天我们就从 MySQL 执行计划EXPLAIN入手带你一眼看穿哪些 JOIN 会“炸库”以及如何快速“灭火”。一、慢 JOIN SQL 的本质是什么MySQL多表 JOIN 的本质是嵌套循环Nested Loop Join一旦某个表被“低效地重复访问”性能就会呈指数级下降。因此所有慢 JOIN SQL 的执行计划本质都暴露了同一个问题某个表被反复扫描却没有走索引二、最致命特征被驱动表 type ALL多表join本质就是再做for循环判断可抽象为for(order表行 oRow : order表){ for(u表的行 uRow : user表){ if(uRow.id oRow.user_id){ return oRow; } } }此处的 order表就是驱动表user表就是被驱动表样例SQLSELECT * FROM orders o left JOIN user u ON o.user_id u.id WHERE o.create_time 2024-01-01 and o.create_time 2024-02-01;问题前提orders.user_id有值user.id没有索引执行计划---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 1 | SIMPLE | o | NULL | range | idx_orders_create_time | idx_orders_create_time | 6 | NULL | 1 | 100.00 | Using index condition | | 1 | SIMPLE | u | NULL | ALL | NULL | NULL | NULL | NULL | 662 | 100.00 | Using where; Using join buffer (hash join) | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- 2 rows in set, 1 warning (0.00 sec)其中user表每次join都会被全表扫描优化方式给被驱动表的连接字段建索引CREATE INDEX idx_user_id ON user(id);三、相关子查询DEPENDENT SUBQUERY执行计划的selectType中出现DEPENDENT SUBQUERY代表子查询依赖外层表无法物化。即外层返回 N 行子查询执行 N 次。样例SQLSELECT * FROM user u WHERE ( SELECT COUNT(*) FROM orders o WHERE o.user_id u.id ) 5;执行计划-------------------------------------------------------------------------------------------------------------------- | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | -------------------------------------------------------------------------------------------------------------------- | 1 | PRIMARY | u | NULL | ALL | NULL | NULL | NULL | NULL | 662 | 100.00 | Using where | | 2 | DEPENDENT SUBQUERY | o | NULL | ALL | NULL | NULL | NULL | NULL | 437625 | 10.00 | Using where | -------------------------------------------------------------------------------------------------------------------- 2 rows in set, 2 warnings (0.00 sec)在 MySQL 8.0 中大部分 EXISTS 相关子查询已经可以被优化为 MATERIALIZED 或半连接只有在“无法去相关”的情况下才会出现 DEPENDENT SUBQUERY。优化写法改写为 GROUP BY HAVINGSELECT u.* FROM user u JOIN ( SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) 5 ) o ON o.user_id u.id; -- 同时添加索引 CREATE INDEX idx_orders_user_id ON orders(user_id);orders 只扫描 1 次在子查询里完成聚合外层 JOIN 用等值关联可走索引四、Using join buffer索引 JOIN 失败的信号如果执行计划的Extra中出现了Using join buffer (Block Nested Loop)8.0较高版本中为hash join则说明JOIN 条件无法使用索引MySQL 使用JOIN Buffer 块嵌套循环SQL样例SELECT o.* FROM orders o JOIN user u ON o.user_id u.id WHERE u.status ACTIVE;问题前提连接条件均有索引但是连接条件的字段类型不一样例如varchar与int比较导致了隐式类型转换无法直接使用索引进行等值匹配而是会调用函数来计算结果执行计划-------------------------------------------------------------------------------------------------------------------------------------------- | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | -------------------------------------------------------------------------------------------------------------------------------------------- | 1 | SIMPLE | u | NULL | ALL | PRIMARY | NULL | NULL | NULL | 100113 | 10.00 | Using where | | 1 | SIMPLE | o | NULL | ALL | NULL | NULL | NULL | NULL | 435000 | 10.00 | Using where; Using join buffer (hash join) | -------------------------------------------------------------------------------------------------------------------------------------------- 2 rows in set, 2 warnings (0.00 sec)优化方式修改连接条件、或更改字段类型五、如何优化多表 JOIN 的慢 SQL很多时候并不是因为数据量本身过大而是由于 JOIN 路径设计不合理导致表被低效、重复地访问。在 EXPLAIN 中看到的各类“危险信号”很多情况下都是在提示某些 JOIN 条件没有有效利用索引触发了不必要的多次扫描。如何一键识别并优化这类慢 SQLDBdoctor提供的SQL审核功能内置多条 JOIN 关联规则自动识别多表关联关联字段类型不一致多表关联被驱动表的访问路径需要走索引表关联可能存在笛卡尔积表连接数量限制多表关联关联字段charset不同可能导致索引失效...SQL审核结果样例点击DBdoctor的 AI-SQL改写功能还可以在不改变语义的情况下对SQL进行优化改写进一步提升SQL性能。DBdoctor 通过精准解析 SQL 与执行计划快速定位 JOIN 性能瓶颈同时结合专家优化经验、外置Cost优化器以及大模型为慢 SQL 提供精准优化建议让查询性能瞬间提升。欢迎下载体验让 SQL 优化从此省心_________________________________________________DBdoctor免*费下载地址https://www.dbdoctor.cn/?utm02点击下方添加小助手微信官方技术支持服务加入技术交流群赠送高阶License