1. 写在前面：为什么多表查询值得单独写一篇

先说个真实场景。我接手过某公司的订单系统，单表数据量不算夸张，也就几百万行。业务方反馈后台订单列表越来越慢，最离谱的查询跑了快20秒——点一次刷新，喝口水的功夫页面才转出来。我第一反应是看索引，结果索引建得没问题，单表查询走主键也都是毫秒级。后来定位到问题在一条关联了五张表的统计SQL上，表连接顺序选错，驱动表选了一个大表，嵌套循环直接炸了。

从那以后我就养成了一个习惯：凡是写多表查询，先停下来想清楚三件事——我要的是哪几类数据、表之间靠什么字段挂钩、用哪种连接方式才能让MySQL少做无用功。这篇东西就是把这些年在多表查询上踩过的坑、总结出的套路一次性整理出来。

适合谁看？刚学会单表增删改查、准备进阶的初学者；写了好几年SQL但从来没认真研究过执行计划的开发者；还有那些被慢查询折磨到想拍桌子的运维和DBA。不敢说你读完就能成为调优大神，但至少能把90%的多表查询写得又快又稳。

多表查询的本质，就是把分散在不同表里的数据按照某种关系重新拼在一起。理解了这个"拼"字，后面的所有内容都是围绕它展开的。

2. 先搞清楚为什么要拆表，才能明白为什么要连接

2.1 不拆表的后果，你想象不到

很多初学者都有一个困惑：数据库表设计得好好的，为什么非要把数据拆成一张张的表，查询的时候再费劲去关联？直接一张大表全塞进去不香吗？

我可以负责任地说：不拆表，短期看确实省事，长期看全是泪。

拿一个最简单的用户系统举例。如果不拆表，你可能会把用户的基本信息、收货地址、订单记录、优惠券、积分流水全部塞进一张表。第一周开发确实爽，查什么都是一条SELECT搞定。等到用户量起来，订单量上来，问题就集中爆发了：

• 单表字段太多，一行数据就占好几KB，InnoDB的聚簇索引叶子节点能存的行数大幅减少，索引效率和缓存命中率双双下降。
• 更新某类信息时要锁一整行，比如用户改个头像，连带他几百条订单记录所在的物理行一起被锁住，并发一高就是死锁重灾区。
• 字段语义混杂，开发人员根本记不清第23个字段到底存的是省还是市，维护成本直线飙升。

拆表的核心逻辑，就是让每张表只关注一个业务实体或一种业务事件，用外键关系（逻辑上的，不一定物理建外键约束）把它们串起来。查询时再通过连接把它们按需组合。这才是关系型数据库存在的意义。

2.2 拆表后，查询就变成了"拼图游戏"

拆完表之后，数据被分散到不同的物理存储位置，但业务上它们仍然是一个整体。多表查询要做的，就是把这些碎片重新拼回来。

一张订单表存订单号、下单时间、订单金额；一张用户表存用户名、手机号、等级；一张订单明细表存商品ID、数量、单价。当你想看"某个用户最近三个月下了哪些订单、订单里买了什么"时，就必须把三张表拼接起来。

这个拼接动作，在MySQL里就是JOIN。你可以把JOIN理解成生活中拼乐高——每块积木有自己的凹凸结构，能拼在一起的积木必须凹凸吻合。表之间的"凹凸结构"就是关联字段，比如订单表里的user_id和用户表里的id，字段类型要一致、含义要对得上，才能严丝合缝地拼在一起。

理解了这一层，你就能明白为什么我强烈建议在设计表结构时，关联字段的类型和命名要保持统一规范。我见过太多项目，一张表里用户ID叫user_id，另一张表里叫uid，还有一张表里叫userid，类型一个int一个bigint一个varchar。关联的时候全靠脑子记，记错了就是隐式转换，索引失效，查询慢得你想骂人。

3. 多表查询的核心姿势：JOIN家族的恩怨情仇

3.1 INNER JOIN：只要交集，别的不谈

INNER JOIN是内连接，也是大多数人最早接触的连接方式。它的逻辑非常简单：只返回两张表中关联字段能匹配上的记录，匹配不上的两边都不要。

这么说吧，你有两张表，一张是学生表，一张是考试成绩表。用INNER JOIN查询的结果，只会包含那些既在表里有档案、又有考试记录的学生。那些报了名但缺考的学生，成绩表里没有他们的记录，INNER JOIN就不会把他们查出来。

SELECT s.name, sc.score FROM students s INNER JOIN scores sc ON s.id = sc.student_id;

这条SQL的意图是：我只关心那些真正参加了考试的学生和他们的分数。缺考的、没报名的，在这个结果里都不出现。

实际开发中，INNER JOIN的使用频率非常高，因为大部分业务场景要的就是这种"两边都有的数据"。比如订单和支付记录关联，你要看的是"已支付订单"；商品和库存关联，你要看的是"有库存的商品"。本质上都是取交集。

有一点必须提醒：INNER JOIN时，关联字段上一定要有索引。否则MySQL需要对两张表做笛卡尔积式的匹配，数据量一大直接慢成PPT。别问我怎么知道的，说多了都是泪。

3.2 LEFT JOIN：左表是老大，一个都不能少

LEFT JOIN的逻辑和INNER JOIN完全不同。它的核心原则是：左表的记录全部保留。左表里有的数据，就算右表没有匹配上，也要出现在结果里，右表的部分用NULL填充。

继续用学生和成绩举例：

SELECT s.name, sc.score FROM students s LEFT JOIN scores sc ON s.id = sc.student_id;

这条SQL会返回所有学生，包括那些缺考没有成绩记录的。没有成绩的学生，score字段显示为NULL。

这个语义在日常开发中极其常用。比如：

• 查所有用户及其最新一笔订单，没有订单的用户也要列出来。
• 查所有商品及其评价数量，没有评价的商品也要展示。
• 查所有部门及其员工数，空部门也要保留。

LEFT JOIN最大的坑在于：如果关联字段不是唯一的，结果集会膨胀。举个具体例子，用户表一条记录对应订单表多条记录，LEFT JOIN之后这个用户会出现多次。新手经常在这种场景下发现数据"变多了"，然后陷入数数的循环。这不是MySQL出了问题，而是你要清楚自己在做什么——一对多关联，结果集的行数自然会放大。

还有一个隐蔽的坑：WHERE条件里如果加了右表的过滤条件，LEFT JOIN可能在不知不觉中就变成了INNER JOIN。比如你想查所有用户以及他们已支付的订单，随手写了WHERE o.status = 'paid'，结果就是：没下过单或只有未支付订单的用户全被过滤掉了，这跟你用INNER JOIN得到的没什么区别。如果确实要保留无订单用户，过滤条件得放到ON子句里：

SELECT u.name, o.id, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid';

这个细节，我至少见过十来个开发者踩过，包括当年的我自己。

3.3 RIGHT JOIN：镜像连接，懂但用得不多的角色

RIGHT JOIN的逻辑和LEFT JOIN完全对称：右表记录全部保留，左表匹配不上用NULL填充。MySQL完全支持RIGHT JOIN，但实际开发中用的人很少。

原因很简单：SQL的可读性讲究从左往右读，大部分开发者习惯把主表放在左边，用LEFT JOIN表达"左表全保留"的语义。RIGHT JOIN虽然也能实现同样的效果，但写出来总觉得别扭。我个人的建议是：能不用就不用，把表换一下位置改成LEFT JOIN，代码阅读性会好得多。

SELECT s.name, sc.score FROM scores sc RIGHT JOIN students s ON s.id = sc.student_id;

这条SQL和上面那条LEFT JOIN结果一样，但读起来就没那么顺。除非你维护的旧代码里已经用了RIGHT JOIN，否则新代码一律推荐LEFT JOIN。

3.4 CROSS JOIN：真正的笛卡尔积，用之前要掂量

CROSS JOIN是纯粹的笛卡尔积，它不需要任何关联条件，直接把左表的每一行和右表的每一行做组合。5张表，每张10行数据，CROSS JOIN的结果就是10的5次方行。

实际业务中，CROSS JOIN用得极少，但有一种场景比较常见：生成测试数据。比如你有10个商品和10个用户，想快速生成100条模拟浏览记录，一条CROSS JOIN就搞定了。再比如某些报表需求，需要把两个维度的所有组合都列出来，也要用到它。

除此之外，我对CROSS JOIN的基本态度是：少碰。一旦参与关联的表数据量稍微大一点，结果集就指数级膨胀，数据库IO直接被打满。这玩意儿用得好是神器，用不好就是事故。

3.5 实战建议：JOIN选型速查表

面对一个具体的业务诉求，怎么快速判断该用哪种JOIN？我整理了一个简单的决策流程：

最后那种场景值得一提。查"没有下过订单的用户"，如果用户有几百万，订单有几千万，用子查询加NOT IN往往性能很差。换成LEFT JOIN加右表主键IS NULL，走索引反连接，速度快得不是一点半点。

SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.id IS NULL;

这个写法在MySQL里等效于NOT EXISTS，但很多场景下执行计划更友好。我在千万级订单表上实测过，比NOT IN快了接近一个数量级。

4. 多表查询的进阶武器：子查询和UNION

JOIN不是多表查询的唯一姿势。有些场景用子查询更直观，有些场景用UNION才符合逻辑，选择比努力更重要。

4.1 子查询：嵌套的"查询中的查询"

子查询就是SELECT里面再套SELECT。它的价值在于把复杂的查询拆解成多个简单步骤，每一步的结果喂给下一步。

最常见的场景是"先用子查询圈定范围，再去做主查询"。比如你想查"最近30天有订单的用户信息"，先查出这30天内有订单的用户ID，再根据这些ID去查用户表：

SELECT * FROM users WHERE id IN ( SELECT DISTINCT user_id FROM orders WHERE order_time >= NOW() - INTERVAL 30 DAY );

这种写法符合人的思考顺序，先找"有哪些人下单"，再找"这些人是谁"，理解成本很低。

但性能上要注意：MySQL对IN子查询的优化在不同版本间变化很大。5.7之前的版本对IN子查询优化得不行，经常出现全表扫描；5.6之后做了子查询优化器，很多场景会把IN子查询转换成SEMI JOIN，性能反而不错。8.0版本整体优化得已经相当好了，但还是建议养成看执行计划的习惯。

如果是"查每个分类下最新发布的商品"这种需求，子查询配合窗口函数（MySQL 8.0+）比传统写法优雅得多。没有窗口函数的话，就得用"关联子查询+LIMIT"，写法丑但也能跑。

4.2 关联子查询：外层一循环，内层一次查

关联子查询的特殊之处在于：内层查询引用外层查询的字段，导致MySQL必须对每一行外层记录执行一次内层查询。逻辑上像一个嵌套循环。

举一个典型场景：查每个学生的最高分科目。

SELECT s.name, sub.subject, sub.score FROM students s LEFT JOIN scores sub ON sub.student_id = s.id WHERE sub.score = ( SELECT MAX(score) FROM scores WHERE student_id = s.id );

这种写法逻辑非常清晰，先找到最高分，再匹配对应科目。但性能隐患明确：外层多少行，内层就执行多少次。如果外层是10万行，内层每次就算走了索引，也是一笔不小的开销。

所以我的建议是：关联子查询能不用尽量不用，优先用窗口函数或JOIN加GROUP BY替代。只有在数据量可控、逻辑确实复杂到别的写法说不清楚时，才考虑它。

4.3 UNION和UNION ALL：纵向拼表，别用错了

很多人把JOIN理解成"横向拼接"——把两张表的列拼在一起。UNION则是"纵向拼接"——把两次查询的结果行拼在一起，但列的结构必须一致。

比如你想查"2024年和2023年销量前10的商品"，但这两个榜单的统计口径完全不同，没办法用一条JOIN搞定，用UNION就顺理成章：

SELECT product_id, year, sales FROM ( SELECT product_id, 2024 AS year, sales FROM sales_2024 ORDER BY sales DESC LIMIT 10 ) t1 UNION ALL SELECT product_id, year, sales FROM ( SELECT product_id, 2023 AS year, sales FROM sales_2023 ORDER BY sales DESC LIMIT 10 ) t2;

UNION和UNION ALL的区别在于去重。UNION会对合并后的结果做去重，UNION ALL则直接把两次查询的结果首尾相接。UNION去重是有代价的，MySQL需要额外做排序或哈希去重，数据量大时性能差距很明显。

所以我的建议是：能确认两边结果不会有交集，或者重复了也不影响业务判断的时候，直接用UNION ALL。很多人习惯性写UNION，其实白白付出了不少性能成本。分布式场景里多个分片查询结果的合并，也是UNION ALL更实用。

5. 多表查询的性能命门：索引和执行计划

5.1 没有索引的JOIN，就是一场灾难

回到文章开头那个案例。订单列表慢的原因查到最后，发现某张关联表的关键字段上压根没建索引。MySQL不得不对这张表做全表扫描，500万行数据逐行匹配一次，不慢才怪。

JOIN操作对索引的依赖远比单表查询严重。单表查询没有合适索引，顶多全表扫一次，数据量再大也就是线性代价。JOIN涉及到多张表，如果关联字段没索引，每驱动一行就要全表扫一次被驱动表，代价是乘法级的。这差距在千万级数据量下堪称天壤之别。

所以，写完一条多表查询，第一件事是检查关联字段上的索引。具体来说：

• 被驱动表的关联字段必须建索引。比如LEFT JOIN中右表的关联字段。
• 驱动表的方向对性能影响也很大。一般原则是用小表驱动大表，让驱动表的行数尽量少。
• 多表关联时，连接顺序由优化器决定，但WHERE条件里的过滤字段有索引也很关键。

5.2 看懂EXPLAIN，看懂MySQL的心思

EXPLAIN是MySQL递给你的"体检报告"，懂它才能知道查询到底卡在哪。我常说，不会看执行计划的SQL开发，写出的查询全靠运气。

一条多表查询的EXPLAIN结果会有多行，每行对应一张表的访问方式。重点关注几个字段：

举个例子：

EXPLAIN SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE u.level = 3;

如果结果里orders那行的type是ALL，rows显示几百万，说明orders表在关联时做了全表扫描。这时候给orders表的user_id建一个索引，往往就能让type变成ref，性能原地起飞。

有人说EXPLAIN看多了会上瘾。确实，每次写完一条复杂的多表查询，执行一下EXPLAIN确认没有全表扫描、没有临时表，心里才踏实。在大型业务系统里，我几乎不允许任何一条上线的复杂SQL不经过EXPLAIN验证。

5.3 驱动表与被驱动表：谁当老大，性能差十倍

JOIN的本质是嵌套循环：从驱动表取一行，去被驱动表里找匹配行，再取下一行，循环往复。所以驱动表的行数直接影响循环次数。

MySQL的优化器通常会选择行数更少的表作为驱动表——也就是用小表去驱动大表。但优化器的判断不是每次都完美，某些情况下它会选错。这时候你就得用STRAIGHT_JOIN强制指定连接顺序：

SELECT STRAIGHT_JOIN u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id;

STRAIGHT_JOIN告诉优化器：不要乱调整顺序，就按我写的从左到右来。这属于非常强的干预手段，一般情况下不建议用，只有在你确认优化器选错了驱动表、且SQL逻辑允许的情况下才值得尝试。

判断驱动表选得对不对，可以看EXPLAIN结果的第一行。第一行就是驱动表。如果驱动表明显是几十万行的大表，而被驱动表是小表，那你很可能遇到了优化器判断失误的场景。

6. 真实案例复盘：一条SQL从20秒到0.3秒的调优实录

6.1 业务背景和原始SQL

某后台系统需要展示"商品销售汇总报表"，要求列出商品名称、所属分类、总销量、总金额、最近一次销售时间。一共涉及四张表：商品表、分类表、订单明细表、订单表。

原始SQL长这样：

SELECT p.name AS product_name, c.name AS category_name, SUM(od.quantity) AS total_qty, SUM(od.price * od.quantity) AS total_amount, MAX(o.order_time) AS last_order_time FROM order_details od JOIN orders o ON od.order_id = o.id JOIN products p ON od.product_id = p.id JOIN categories c ON p.category_id = c.id GROUP BY p.id, c.id ORDER BY total_amount DESC LIMIT 100;

这张报表背后的数据规模是：订单表约3000万行，订单明细表约8000万行，商品表10万行，分类表几百行。SQL一执行就是十几秒到二十秒，后台页面直接超时。

6.2 问题定位：EXPLAIN暴露了真相

执行EXPLAIN之后，问题一目了然：

• 订单明细表作为驱动表，但它的product_id和order_id都没有适合的复合索引，关联时只能全表扫描。
• 商品表关联时，category_id上也没有索引。
• 结果集先做了GROUP BY，再ORDER BY total_amount DESC，产生了临时表和文件排序，进一步拖慢了速度。

三个问题叠加，20秒一点不冤。

6.3 一步步改：索引、改写、再验证

第一步，加索引。给订单明细表建了一个复合索引(order_id, product_id)，给商品表建了(category_id)。这两个索引让关联阶段的扫描量直接降下来。

第二步，改写GROUP BY和ORDER BY。原SQL先分组再排序，数据量大了优化器容易选择临时表+文件排序。考虑到业务上实际只需要销量前100的商品，可以先把子集缩小再聚合排序。

改写后的SQL长这样：

SELECT p.name AS product_name, c.name AS category_name, s.total_qty, s.total_amount, s.last_order_time FROM ( SELECT od.product_id, SUM(od.quantity) AS total_qty, SUM(od.price * od.quantity) AS total_amount, MAX(o.order_time) AS last_order_time FROM order_details od JOIN orders o ON od.order_id = o.id GROUP BY od.product_id ORDER BY total_amount DESC LIMIT 100 ) s JOIN products p ON s.product_id = p.id JOIN categories c ON p.category_id = c.id;

这个改写的核心思路是：把最重、最大的表（订单明细+订单）先缩到100行，再和商品表和分类表做关联。连接的数据量从千万级缩小到百行级，整条SQL成本完全不在一个量级。

最终这条SQL的耗时在0.3秒左右，下降了六十多倍。

6.4 这个案例教会我的事

这个案例给我留下了非常深的印象，三点经验分享给各位：

第一，加索引永远是最便宜的优化手段。很多慢查询的问题根本不是什么深奥的架构问题，就是缺了一个索引。动手写SQL之前，看看关联字段和WHERE字段有没有索引，能解决一大半问题。

第二，能先缩小数据集，就不要直接在大数据集上聚合。SQL的优化核心思想就一个字：少。少扫描、少关联、少排序。子查询先LIMIT再关联，是应对大表JOIN非常实用的一招。

第三，改动一定要用EXPLAIN验证。我第一次优化完，顺手看了EXPLAIN，发现rows确实降了，但临时表还在。又调整了索引结构才算真正解决。没有执行计划的调优就是闭着眼开车，全靠运气。

7. 容易踩的坑：多表查询的常见翻车现场

7.1 隐式类型转换：你以为走索引，其实没有

表里user_id是varchar类型，查询的时候传了整数类型，或者关联时另一张表的关联字段是int，MySQL会做隐式类型转换。麻烦在于：一旦对索引字段套了函数或隐式转换，索引就失效了。

SELECT * FROM orders WHERE user_id = 123456;

如果user_id是varchar，这条SQL看起来没什么问题，但MySQL在比较之前要把user_id的每个值都转成数字，索引直接失效，全表扫描。

正确姿势是：

SELECT * FROM orders WHERE user_id = '123456';

关联两张表时也一样，两边字段类型必须一致，至少也要兼容。设计表结构的时候把关联字段的类型定死，varchar就全varchar，int就全int，能省掉无数后期的坑。

7.2 一对多关联导致的数据膨胀

用户表一条记录关联订单表五条记录，LEFT JOIN出来的结果就是五行。如果业务上只想要用户加上他某笔订单的信息，这就不是预期结果了。

落到实战里，最典型的是"用户和订单表关联后统计用户数"。比如你要统计下单用户总数，直接COUNT(DISTINCT u.id)是一回事，直接COUNT(*)就变成统计订单条数了。我见过不止一次报表里数字莫名偏大，查到最后发现就是少了个DISTINCT。

处理方案无非两种：一是用DISTINCT去重，二是把一对多关联拆成子查询，在子查询里先聚合，再关联。数据量大的场景里，后者的性能要好得多。

7.3 ON条件和WHERE条件的混淆

这个坑我在前面提到过，但值得单独再说一次。LEFT JOIN的ON条件控制的是"哪些左表记录能找到匹配"，WHERE条件则是在连接完成后再做筛选。把本该放ON的过滤条件放到WHERE，LEFT JOIN就悄悄变成了INNER JOIN。

-- 错误示范：右表过滤条件放WHERE，无订单用户被过滤掉 SELECT u.name, o.id FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'; -- 正确示范：过滤条件放ON，保留所有用户 SELECT u.name, o.id FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid';

两者的结果可能完全不同。前者只返回有已支付订单的用户；后者返回所有用户，有的订单，有的没有。业务语义不一样，写错了看似都能跑，结果差之千里。

7.4 LIMIT分页深翻页的隐患

多表查询配合分页是后台管理系统的常规操作，但LIMIT的深翻页问题经常被忽略。LIMIT 1000000, 20这种写法，MySQL要先扫到1000020行，再扔掉前100万行，代价极高。

优化方案一般两类：

一是延迟关联。先自连接或子查询只查主表ID，拿到需要的ID范围后再关联其他表：

SELECT ... FROM orders o JOIN ( SELECT id FROM orders ORDER BY create_time DESC LIMIT 1000000, 20 ) tmp ON o.id = tmp.id JOIN users u ON o.user_id = u.id;

二是基于游标的分页。记录上一页最后一条记录的主键或排序字段值，下一页就用WHERE id > 上次的最大id ORDER BY id LIMIT 20。没有跳页需求的话，这是最优解。

8. 多表查询的日常修炼：如何写出又快又稳的SQL

8.1 三个习惯，帮你少踩一半深坑

第一，写任何多表查询，先画逻辑图。一张纸就行，把涉及的每张表画成方块，用线连出关联关系，标清楚哪张是驱动表、哪张是被驱动表、最终需要哪些字段。这能帮你提前发现关联顺序和结果集膨胀的问题，比对着编辑器硬想高效得多。

第二，默认所有多表查询都要过一遍EXPLAIN。不管看起来多简单的JOIN，养成执行EXPLAIN的习惯，看type是不是ref、key是不是有值、rows大概多少。三秒钟的事，省下的调试时间按小时计。

第三，字段数量和SELECT范围遵循最小化原则。很多人图省事直接SELECT *，在多表JOIN场景下，这会把所有表的全部字段都捞出来，不仅增加网络传输开销，还可能让MySQL选择更笨重的执行计划。只要用到的字段，别多选一个。

8.2 写SQL前的自问清单

每次写多表查询，我习惯问自己五个问题：

1. 这次查询需要哪几张表？能不能少关联一张？
2. 关联字段是什么？类型一致吗？有索引吗？
3. 用INNER JOIN还是LEFT JOIN？业务语义到底是什么？
4. 有没有一对多关联？结果集会不会膨胀？
5. 需要在子查询里先聚合/先LIMIT吗？

这套自问清单帮我挡掉了无数潜在的性能事故。前段时间一个同事写的后台报表，直接五千字评论区的表全JOIN了一遍，光JOIN就有八张表。我拿着清单逐项问他，问到第三个问题他就意识到自己多关联了三张压根用不到的表。删掉之后SQL快了一倍。

8.3 工具推荐：让EXPLAIN不再难读

MySQL Workbench自带的Visual Explain，能把执行计划画成图形，色块越红越危险，一张图看明白所有表的关联顺序和扫描方式，对新手极其友好。

日常调优我还会用pt-query-digest分析慢查询日志，找出哪些多表查询是"高频+慢"，优先优化这些。绝大部分数据库性能问题，都是少数几条SQL占了绝大多数负载。把这两三条SQL优化好，整个系统就稳了一大半。

9. 最后分享一点个人体会

做了这么多年开发，MySQL多表查询是我见过翻车率最高的SQL操作类型。它涉及的知识点很杂，既有SQL语法层面的JOIN类型选择，又有表结构设计层面的关联字段规范，还有数据库内核层面的索引和执行计划。任何一个环节出问题，最终都表现为同一种症状：查询变慢。

但反过来讲，多表查询也是最能体现"基本功"的地方。那些能一眼看出慢查询原因、三分钟给出优化方案的开发者，无一例外都对JOIN的底层逻辑、索引的数据结构、执行计划的解读烂熟于心。

我自己带人的时候，不管新人还是资深，但凡写SQL，都要求先给我讲清楚这个查询的驱动表是谁、走什么索引、为什么选这种连接方式。讲不清楚，说明没理解透，写出来的SQL大概率是有问题的。

如果你现在正被某条多表查询折磨得焦头烂额，我的建议是：别急着在SQL层面瞎试，先退一步，从表结构和索引开始看。大多数病根不在SQL写法，而在更底层的地方。把地基夯实了，上面的房子自然稳固。