1. JOIN类型选型与执行逻辑拆解1.1 为什么你写的联合查询比同事的慢十倍先聊一个我经常被问到的问题同样是两张表关联为什么别人跑几十毫秒你写出来就是几百毫秒甚至直接超时大部分情况下问题不在数据库而在于你根本不知道MySQL 8的优化器是怎么处理JOIN的。MySQL 8的联合查询JOIN本质上是一个嵌套循环的过程。你可以把它理解成两层for循环外层驱动表每读取一行内层就去匹配目标表中符合条件的行。听起来很简单对吧但这里面牵扯到两个关键问题驱动表选谁、内层如何加速匹配。前者决定了外层循环的次数后者决定了每次匹配的代价。很多新手只关注SQL能不能跑出正确结果忽略了这两点于是性能就崩了。以一条实际业务为例。假设我们有订单表orders50万行和用户表users10万行想查每个订单对应的用户名。如果写成SELECT o.order_id, u.user_name FROM orders o JOIN users u ON o.user_id u.user_id;乍一看没问题但执行的时候MySQL优化器会估算哪个表作为驱动表更合适。如果orders被选为驱动表那就要做50万次内层查找如果users被选为驱动表只是10万次。虽然优化器会自动选但它依赖统计信息。当表的统计信息过期、或者你写的ON条件让优化器无法准确估算时选错驱动表的代价是致命的。所以理解JOIN的第一步不是背语法而是看懂“嵌套循环”的本质。当你明白了驱动表和被驱动表是怎么配合的后面所有优化手段——索引、缓冲池、执行计划——都会豁然开朗。1.2 五种JOIN类型分别解决什么场景MySQL 8支持五种常见的JOIN形式我分别说下它们的核心语义和使用场景。INNER JOIN内连接只返回两表匹配成功的行。这是最常用的适合过滤掉不相关的数据。比如查有支付记录的订单、有库存的商品都是内连接的典型场景。LEFT JOIN左连接返回左表的全部行右表能匹配上就返回字段匹配不上就补NULL。常用于“主表全量展示、副表补充信息”的场景。比如展示所有用户附带他们最近的订单信息——没有订单的用户也得出现在列表里订单字段留空。RIGHT JOIN右连接与LEFT相反返回右表全部行。因为LEFT JOIN可以改写法达到同样效果实际业务里RIGHT JOIN用得相对少但了解它有助于阅读老代码。CROSS JOIN笛卡尔积两表行数相乘不带ON条件。这个一般不建议在生产环境直接使用除非你明确要做排列组合类的计算。SELF JOIN自连接一张表自己连接自己常用于层级结构、好友关系等场景。比如员工表里查“每个员工的上级姓名”就是同一张表做两次查询再关联起来。还有个容易被忽视的点JOIN的顺序并不等于SQL里写的顺序。MySQL优化器会把表重新排序选择最优的执行路径。这在只用几张表时不明显但当你连着四五张表时优化器的重排结果往往和你想象的完全不一样。所以别在代码注释里写“按顺序执行”这种误导自己的话。1.3 条件放在ON与WHERE里的结果天差地别这是我认为联合查询里最容易踩的坑没有之一。很多开发者在LEFT JOIN的时候把筛选条件顺手写在WHERE里结果数据不知不觉就“变少”了。举个例子。你要查所有用户以及他们2024年的订单金额SELECT u.user_id, u.user_name, SUM(o.amount) AS total_amount FROM users u LEFT JOIN orders o ON u.user_id o.user_id WHERE o.order_date 2024-01-01;这个SQL看着没问题但实际效果等同于INNER JOIN——因为WHERE里的条件会把右表中不满足条件的行过滤掉连带着LEFT JOIN保留左表全量的效果也被抵消了。正确写法是把时间条件放到ON子句里SELECT u.user_id, u.user_name, SUM(o.amount) AS total_amount FROM users u LEFT JOIN orders o ON u.user_id o.user_id AND o.order_date 2024-01-01;两者的区别在于ON子句的过滤发生在“两表匹配”的过程中它还保留了左表的所有行而WHERE的过滤发生在“JOIN完成之后”这时候NULL行也会被一并剔除。我见过不少生产事故是这么来的报表数据突然少了一大批查了半天最后发现是有人把关联条件误放进WHERE。记一个简单的口诀内连接里ON和WHERE等价外连接里能放ON就别放WHERE。2. 索引与关联字段的底层逻辑2.1 JOIN慢的根源九成在索引设计聊完JOIN的类型接下来是实战中收益最明显的部分索引。要明白索引是怎么影响联合查询的先回到嵌套循环的本质。外层驱动表每读一行内层被驱动表就要根据ON条件去找匹配行。如果没有索引内层就要做全表扫描。外层10万行内层全表扫描哪怕是百万级的小表扫描次数也能到几十亿次数据库直接卡死。所以在被驱动表的关联字段上建索引几乎是JOIN性能优化的第一条铁律。这个索引的作用不是加速“单表查询”而是让嵌套循环内层每次都能通过索引快速定位。理想情况下被驱动表关联字段的索引类型应该是二级索引且基数较高的字段这样存储引擎能快速把匹配行缩小到很小的范围。以orders表为例建索引的方式要注意优先级ALTER TABLE orders ADD INDEX idx_user_id (user_id); ALTER TABLE orders ADD INDEX idx_user_date (user_id, order_date);如果你经常按用户和时间两个维度做关联和过滤联合索引idx_user_date比单一索引idx_user_id更优因为它既能加速user_id的匹配又能利用order_date做范围过滤。但要小心一个原则索引最左前缀。如果你建的联合索引是(user_id, order_date)而查询里只用了order_date做条件这个索引就完全用不上。这里分享一个我实测过的案例。某核心报表关联了四张表最慢时跑了45秒。加上合适的联合索引之后同样的查询降到1.2秒。整个过程没改一行SQL纯粹是索引让嵌套循环内层的匹配从全表扫描变成了索引查找。所以说慢JOIN排查第一步永远是看执行计划而不是急着改写SQL语句。2.2 索引失效的几大隐形杀手有时候你明明建了索引EXPLAIN结果却显示typeALL说明索引没生效。我总结了一下最常见的几个隐形杀手关联字段类型不一致。这是最经典的坑。一张表user_id是bigint另一张表user_id是varcharMySQL在比较时会做隐式类型转换一旦字段发生了类型转换索引就失效了。解决办法是统一两表的关联字段类型或者在设计阶段就约定好全局规范。字符集不一致。这个比类型不一致更加隐蔽。MySQL 8默认是utf8mb4但老项目可能还有表是utf8或latin1。两张表字符集不一样JOIN时MySQL会先把一侧字段转换再比较索引同样会失效。查元数据的方法很简单SELECT TABLE_NAME, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA your_db;LIKE模糊匹配前缀通配符。比如ON a.code LIKE %abc%这种条件就算有索引也用不上只能全表扫描。如果业务确实需要前缀模糊查询考虑用全文索引或改成前缀匹配。对索引列做了函数运算。例如WHERE DATE(o.order_date) 2024-01-01这样一包装索引立刻失效。正确做法是写成o.order_date 2024-01-01 AND o.order_date 2024-01-02。我在实际项目里遇到过最无语的案例是开发者把user_id字段设计成了int后来业务扩展改成了varchar(20)但旧数据里的数字没有补零新数据里有字母开头。结果关联查询时MySQL总是做隐式转换索引全废一个简单的两表连接跑了20多秒。最后花了半天时间清洗数据统一类型之后才恢复速度。这件事给我一个教训建表时关联字段的类型和字符集就得定死宁可后面改业务不要轻易改字段定义。2.3 驱动表怎么选优化器说了算很多人在网上看帖子说“LEFT JOIN的左表就是驱动表”这种说法其实不准确。准确的是优化器决定驱动表不一定会遵循书写顺序尤其MySQL 8的优化器会基于成本模型做重排。优化器选择驱动表的依据主要看两个维度一是参与连接的行数估算二是连接字段的可选择性。行数小、可选择性高的表做驱动表可以大幅度减少内层匹配次数。举个例子SELECT * FROM big_table b LEFT JOIN small_table s ON b.key s.key;虽然你写的是big_table在左但如果优化器发现small_table过滤后只剩下几十行它会果断改成以small_table为驱动表。对开发者来说不需要手动去“指定”驱动表但你需要确保统计信息是准确的。MySQL 8默认开启innodb_stats_auto_recalc刷数据量大的时候最好手动执行ANALYZE TABLE orders;这一步就是告诉优化器“我的数据变了请更新统计信息”。很多时候你以为SQL写得烂其实只是统计信息过期了执行计划跑偏而已。注意MySQL 8.0中如果查询里使用了STRAIGHT_JOIN可以强制表连接顺序但绝大部分场景不建议这么干。让优化器自己判断把ANALYZE TABLE、索引建好比手工干预更稳。2.4 联合索引设计的三个层次围绕JOIN的索引设计我建议所有开发人员按三个层次来思考。第一个层次是单表过滤WHERE条件里涉及的字段要保证有索引可走。比如你按状态和时间过滤一张表最好建(status, create_time)联合索引让过滤直接落在索引扫描范围内。第二个层次是连接匹配ON条件里的字段必须确保被驱动表那一侧有索引。这是所有JOIN查询的最低要求。没有索引的话无论你SQL写得多优雅底层都是全表扫描谁来了都救不了。第三个层次是覆盖索引SELECT子句里所需的字段尽可能包含在索引中。这样InnoDB可以直接从二级索引里返回结果连回表都不需要。举个例子查询只需要order_id和user_name如果orders表有(user_id, order_id)的联合索引优化器就可以直接覆盖扫描省掉回表I/O。这三个层次是我做SQL优化的思维框架。先看过滤再看连接最后看SELECT字段。层层递进基本能把90%的慢JOIN问题覆盖掉。剩下的10%就交给执行计划和缓冲池参数去调整。3. EXPLAIN执行计划慢查询的诊断起点3.1 看懂EXPLAIN输出的关键字段任何MySQL联合查询排查问题的第一步永远是EXPLAIN。老规矩在你的SELECT前面加上EXPLAIN关键字MySQL 8会返回一行或几行执行计划信息。这里说几个最关键、也是我每次必看的字段type访问类型性能从好到差依次是system const eq_ref ref range index ALL。看到ALL就说明是全表扫描需要警惕。eq_ref是JOIN被驱动表最理想的状态说明每行只匹配一行性能极好ref则说明用到了非唯一索引也算正常range是范围扫描也能接受。key实际用到的索引名。如果显示NULL说明没有命中任何索引。rows预估扫描的行数。这个值越大查询越慢。但它只是估算值实际执行时可能偏差较大。Extra这里是信息宝库。看到Using where说明有过滤Using index说明索引覆盖Using temporary说明SQL里用了临时表通常会伴随文件排序Using filesort说明需要额外排序最好通过索引消除。key_len用到的索引长度。字节数越大说明用到的索引列越多。这个字段能告诉你联合索引是否用全了。以实际案例示范一下EXPLAIN SELECT u.user_id, o.order_id FROM users u LEFT JOIN orders o ON u.user_id o.user_id WHERE u.status 1;假设结果里users表的type是reforders表的type是eq_ref说明两边索引都命中这就很理想。如果orders表的type是ALL那你的orders表user_id列一定没有索引得回去补建。3.2 Using join buffer到底在提示什么EXPLAIN的结果里如果出现Using join buffer (Block Nested Loop)很多人一看到就慌了以为出了大问题。其实它表达的意思是被驱动表没有有效索引MySQL无法一条条去索引查询只能把驱动表一批行加载进内存然后和被驱动表整体做匹配。这听起来像是一种优化手段减少I/O擦次数但实际上它是个性能预警。当你看到这个提示意味着你的ON字段缺索引或者关联条件复杂到无法走常规索引。MySQL 8.0.18以前这个机制叫Block Nested Loop之后版本引入了Hash Join所以提示也可能变为Using join buffer (Hash Join)。Hash Join会在被驱动表无索引时通过构建hash表来加速匹配但这只是从“全表扫描全表扫描”的灾难中挽救一下有索引永远是首选。我在一次优化中见过这样的查询大表A和小表B做LEFT JOINB表只有2000行按说不大但因为没有索引执行计划出现Using join buffer耗时约2秒。我加了索引后直接变成eq_ref耗时降到50毫秒。差距就是这么直观。实操心得如果你的表很小几千行以内偶尔出现Using join buffer未必是灾难因为hash join一版很快。但如果你每次都出现说明索引设计存在系统性问题必须修。3.3 从执行计划反推SQL写法是否正确执行计划不仅能观察性能还能“验证语法直觉”。我手上有一个真实场景某活动报表需要统计每个用户的付款总额、退款总额并关联用户标签。最初写法是两个LEFT JOIN各自对子表聚合但EXPLAIN显示两张子表都要全表扫描并生成临时表整体查询跑了15秒。后来我改写成了“先聚合、后连接”的方式先把订单和退款在子查询里各自汇总好再一次性JOIN上来。EXPLAIN显示子查询扫描行数大幅下降总耗时降到1.8秒。这个经历也验证了一个mysql 8联合查询的老原则能在子查询里过滤和聚合的就不要让JOIN外套层大聚合减少传输进JOIN的行数。你可以把EXPLAIN当成一面镜子每次写完复杂的联合查询先EXPLAIN一遍看看预估行数和type是否合规再决定要不要调整。这个过程本身就是在训练SQL直觉。4. 常见翻车场景与优化技巧实录4.1 笛卡尔积忘写ON条件的灾难新手最容易犯的错就是JOIN不带ON比如SELECT * FROM users u, orders o;这样写两表行数直接相乘返回数据量爆炸。如果两表各有10万行结果就是100亿行——数据库基本直接失去响应。这种问题在代码走查时也比较容易被发现但还有一种情况很隐蔽虽然写了ON但条件写错了比如关联到两个无关字段也存在隐式笛卡尔积的风险。排查这类问题很简单先看返回行数是否正常再检查JOIN条件有没有用上索引最后看EXPLAIN的rows列——如果驱动表和被驱动表的rows乘积远大于实际预期基本可以断定是关联条件搞错了。我的建议是生产环境禁用无JOIN条件查询。如果是测试需要故意生成笛卡尔积也要加上LIMIT限制行数防止一次性拖垮数据库。4.2 NULL陷阱LEFT JOIN后查询条件哪去了前面提到过ON和WHERE的区别这里再扩展一个NULL相关的坑。LEFT JOIN之后右表匹配不到的字段是NULL但如果你在WHERE里写上WHERE o.amount 100NULL行会被直接过滤掉。很多人以为“查了没订单的用户顺便过滤金额”实际上是“查了有订单且金额大于100的用户”两者语义截然不同。另一个常见问题是做聚合时NULL值会被自动忽略。比如用COUNT(o.order_id)统计订单数没订单的用户显示0但用SUM(o.amount)统计金额时没订单的用户显示NULL而不是0。这个细节在前端展示上会出事得用IFNULL包一层。这类问题的根本原因是没想清楚LEFT JOIN之后NULL的含义。你每次写外连接查询时都应该问自己一句右表这行为空我的业务逻辑能正确处理吗4.3 JOIN多张表时关联字段的规范化建议当你需要关联5张以上的表时可读性和性能都会急剧下降。我踩过几次坑后总结了一套规范化流程分享给大家。第一步统一关联字段命名。在一个库中用户ID就叫user_id不要这张表叫uid那张表叫customer_id。统一命名让你一眼就看明白关联关系也方便后续维护。第二步统一字段类型和字符集。全库统一bigint就全用bigint字符串全用utf8mb4。这能避免大量隐式转换导致的索引失效问题。说到底联合查询的性能隐患很多在设计阶段就埋下了。第三步控制JOIN表的数量。MySQL 8优化器处理十几张表的JOIN会变得吃力执行计划的搜索空间呈指数级增长。如果业务非要这么多表先考虑是否能用冗余字段替换或者拆成多个子查询再合并。第四步优先过滤再连接。能提前缩小数据集的就在子查询或CTE里缩。大集合JOIN小集合永远比两个大集合直接JOIN快。这个思路类似于做菜前先把食材洗净切好而不是直接下锅再挑拣。4.4 用EXISTS替代INNER JOIN的边界条件有些场景下用EXISTS替代INNER JOIN能获得更好性能。典型例子是“查有订单的用户列表”你只需要返回用户信息不需要订单字段SELECT u.* FROM users u WHERE EXISTS ( SELECT 1 FROM orders o WHERE o.user_id u.user_id AND o.status 1 );这里EXISTS的好处是只要在内层查到第一条匹配就立即返回不再继续扫描。如果orders表user_id上有索引EXISTS查询整体开销很低而且避免了JOIN结果集的膨胀。但注意不要神话EXISTS。如果你确实需要订单表的字段还是得INNER JOIN。没有银弹只有场景匹配。我遇到过一个开发者因为听说EXISTS性能好就把所有JOIN都改写成EXISTS结果子查询条件复杂后反而比JOIN慢得多。所以任何优化方案都要先实测再推广。4.5 小结果集驱动的优化实例有一段时间我负责一个后台权限系统其中的角色、菜单、权限关联查询一直有点慢。最开始的SQL长这样SELECT r.role_name, m.menu_name, p.permission_code FROM roles r LEFT JOIN role_menu rm ON r.role_id rm.role_id LEFT JOIN menus m ON rm.menu_id m.menu_id LEFT JOIN role_permission rp ON r.role_id rp.role_id LEFT JOIN permissions p ON rp.permission_id p.permission_id;这SQL逻辑正确但四张表全量关联EXPLAIN里好几处ALL用户量一大就扛不住。优化思路很直接先把当前用户的角色过滤出来小结果集再按需关联SELECT r.role_name, m.menu_name, p.permission_code FROM ( SELECT role_id, role_name FROM roles WHERE status 1 ) r LEFT JOIN role_menu rm ON r.role_id rm.role_id LEFT JOIN menus m ON rm.menu_id m.menu_id LEFT JOIN role_permission rp ON r.role_id rp.role_id LEFT JOIN permissions p ON rp.permission_id p.permission_id;第一步先把roles表缩小再通过索引逐级关联。加上每个关联字段的索引之后这个查询从300ms降到30ms效果非常明显。道理就一条先减少行数再做连接匹配。5. MySQL 8的新特性CTE与窗口函数让JOIN更强大5.1 WITH子句拆解复杂查询MySQL 8之前复杂的联合查询要么靠嵌套子查询要么靠临时表。MySQL 8引入了公用表表达式CTE用WITH关键字声明一个临时命名的结果集后续查询可以反复引用。这对我这样的老开发者来说是极大的可读性提升。比如你要统计每个部门的人数和平均薪资关联了三张表。老写法是嵌套三层子查询维护起来头皮发麻。新写法可以这样WITH dept_stats AS ( SELECT d.dept_id, d.dept_name, COUNT(e.emp_id) AS emp_count, AVG(e.salary) AS avg_salary FROM departments d LEFT JOIN employees e ON d.dept_id e.dept_id GROUP BY d.dept_id, d.dept_name ) SELECT * FROM dept_stats WHERE avg_salary 8000;CTE的优点在于第一可读性大幅提升每个命名结果集代表了业务语义的一个步骤第二我们不需要担心它和子查询的性能差异因为MySQL 8的优化器会把CTE物化或内联执行取决于成本估算。不过要注意不是所有CTE都一定执行得更高效。如果CTE被引用多次MySQL可能会物化它占用临时空间。实际使用时核心还是要根据EXPLAIN结果判断。CTE更重要的意义是让SQL更接近人的思维方式而不是给你一个性能银弹。5.2 窗口函数与JOIN的组合玩法MySQL 8的窗口函数ROW_NUMBER、RANK、LAG等对联合查询也产生了深远影响。以前“查每个用户最近一笔订单”是SQL界的经典难题要么用嵌套子查询要么用变量写法又长又容易错。现在有了窗口函数直接上ROW_NUMBERSELECT user_id, order_id, order_date FROM ( SELECT o.user_id, o.order_id, o.order_date, ROW_NUMBER() OVER (PARTITION BY o.user_id ORDER BY o.order_date DESC) AS rn FROM orders o ) ranked WHERE rn 1;这个查询先用窗口函数在order表内部按用户分组排序然后外层过滤出rn1的行最后想关联users表就再JOIN一次。整个过程既不用写复杂的相关子查询也不用担心临时表带来的额外损耗。我在实际做数据报表时特别喜欢把窗口函数和CTE搭配起来用。先CTE做基础数据准备再窗口函数做排名和排序最后JOIN维度表补全字段。SQL看起来像流水线作业每一步职责清晰不仅好维护性能也几乎没有额外的坑。5.3 递归CTE层级数据的替代方案层级数据比如菜单树、部门树、分类结构以前是开发者的痛点。老方案是自己写递归程序或是一层层查数据库。MySQL 8支持递归CTE之后一条SQL就能生成完整的层级路径。WITH RECURSIVE dept_tree AS ( SELECT dept_id, dept_name, parent_id, 1 AS depth FROM departments WHERE parent_id IS NULL UNION ALL SELECT d.dept_id, d.dept_name, d.parent_id, dt.depth 1 FROM departments d JOIN dept_tree dt ON d.parent_id dt.dept_id ) SELECT * FROM dept_tree;这里UNION ALL两边分别是锚点成员和递归成员MySQL会不断用递归成员的结果推进直到没有新的层级。递归CTE结合JOIN连父表的名称都可以直接在递归过程中补全。唯一要注意的是设置递归深度或条件终止因为MySQL默认有cte_max_recursion_depth的限制防止无限递归把数据库跑爆。如果你维护的系统里有很多树形业务结构把递归CTE用起来会省掉大量代码和查询轮次这个技能点非常值得投资。6. 参数调优与沟通协作的工程化沉淀6.1 关键参数与日志诊断MySQL 8联合查询的调优除了改SQL和索引之外有些参数也会影响执行效率。简单列几个重点join_buffer_size联合查询时如果需要join buffer这个参数控制缓冲区大小。默认值偏小256KB对复杂的多表JOIN可能不够。但别一上来就调到1GB内存是有限的很多小查询并不会用到这么大的缓冲区。建议从4MB开始压测观察效果再微调。innodb_buffer_pool_sizeInnoDB的缓冲池直接影响索引页和数据页的命中率。内存允许的情况下这个值设为物理内存的70%左右是最常见的做法。缓存命中率高了JOIN时读索引页的I/O就少了。optimizer_switchMySQL 8的优化器有一些开关比如mrr_cost_based、block_nested_loop。绝大多数情况保持默认即可不建议乱关。只有当你仔细阅读执行计划并确认某个优化策略导致性能倒退时才考虑在会话级别临时关闭。slow_query_log开启慢查询日志记录超过阈值的SQL。这是定位线上慢JOIN的第一手段。你要把long_query_time设置合理比如1秒然后定期巡查日志把TOP N慢SQL捞出来分析。生产环境里我的习惯是调参前先把慢SQL、执行计划、索引状态三者一起拍照留档。调完参数后再次对比。如果没有对比数据调优就是盲人摸象。6.2 规范先行把性能隐患消灭在设计阶段最后聊一点可能不那么技术、但比技术更影响长期效率的事规范。我工作这些年见过太多联合查询性能问题根源其实在表结构设计阶段就埋下病根了。比如关联字段类型参差不齐、字符集不统一、缺少外键逻辑约束、没有提前规划索引。等到业务跑起来数据量上去了再去调SQL和索引都是补救不是治本。我建议你的团队内部形成一份简单的数据库开发规范至少包含以下几项所有表必须有主键并且是自增int或雪花id关联字段统一命名、统一类型字符串统一utf8mb4每个查询必须EXPLAIN复看生产环境禁止无条件JOIN复杂联合查询必须经过DBA review。这些条目听起来基础但坚持执行的团队线上慢查询的数量会少一个数量级。6.3 几个亲测有效的排查小技巧再分享几个我平时排查联合查询时的土方法都是反复验证有效的LIMIT大法一个慢JOIN不知道问题在哪直接在SQL后面加LIMIT 1如果能快速返回说明是结果集太大或排序太慢如果加了LIMIT还是很慢说明连接本身或过滤条件有问题。逐步拆表法把多表JOIN的SQL一层层拆开先只查第一张表再加上第二张、第三张逐步观察时间变化哪一步突然暴增问题基本就锁定在哪一步。COUNT试探法对每张表单独统计关联字段的COUNT和DISTINCT COUNT判断数据分布是否均衡。如果某个值占了90%的行索引可选择性太差容易发生扫描偏差。改写对比法同一个查询尝试用LEFT JOIN、INNER JOIN、EXISTS、NOT EXISTS各写一遍EXPLAIN对比。有时候写法不同优化器的执行路径差别很大选最优的保留。这些方法都不需要复杂工具纯靠SQL就能完成适合大多数人快速上手。我以前带新人的时候会让他们先学会拆表排查再学EXPLAIN最后才教参数调优。顺序搞反了容易一头扎进mysql 8联合查询的细节里出不来。6.4 团队协作中的加索引流程说个现实的问题即使你知道要加索引生产环境也不是你随手一条ALTER TABLE就能执行的。大表加索引会锁元数据影响线上写入。这时候要考虑在线DDL工具或者选择业务低峰期执行。我以前在一个电商团队遇到核心订单表需要加联合索引就是在凌晨2点窗口期执行的。这里分享一个经验加索引之前先把要执行的DDL写成review文档写明影响行数、预计耗时、是否需要复制延迟观察再拉上运维一起确认。哪怕这条SQL很简单也值得走这个流程。因为你面对的不只是技术还有线上的可用性。另外执行完加索引之后别急着和业务说优化完成。先用EXPLAIN确认新索引是否被优化器采纳再跑一轮原SQL对比耗时最后观察慢查询日志里还有没有类似SQL。四步都走完才算是真正闭环。6.5 一次联合查询优化的完整复盘最后给大家走一遍我最近处理的一个真实问题也算是对前面所有内容的串联。业务侧反馈有个统计页面打开要5秒定位是这条SQLSELECT u.user_name, COUNT(o.order_id), SUM(o.amount) FROM users u LEFT JOIN orders o ON u.user_id o.user_id LEFT JOIN order_items oi ON o.order_id oi.order_id WHERE u.user_level 3 AND o.order_date DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY u.user_name;第一步EXPLAIN看到orders表是ALLorder_items表也是ALL。再查索引orders表只有主键索引没有user_id索引和order_date索引order_items表只有主键索引。第二步拆表先只查users表过滤出user_level3的用户行数约1万很快再连orders表时间暴涨。原因很明确orders表没有user_id索引每次都要全表扫描。第三步加索引。我给orders表加了(user_id, order_date)联合索引给order_items表加了order_id索引。第四步重新EXPLAINorders表变成reforder_items表变成eq_refrows从几十万降到几百。最终查询从5秒降到0.2秒。整个过程用时不到半小时没改一行SQL全靠索引和执行计划。这就是联合查询优化的常态大多数时候不是拼绝活而是老老实实把索引、执行计划、数据分布这三件事理清楚。我个人这几年最大的体会是MySQL 8联合查询没有玄学嵌套循环的执行模型就摆在那里优化空间是可以计算出来的。只要你有耐心看执行计划用规范约束设计sql写法和索引配合得当慢查询的问题大多数都能在半小时内定位到根因。希望这篇里讲到的技巧能给正在被慢JOIN折磨的你一些实质性的帮助。