企业官网建设流程全解析

一开始接触MySQL的时候，很多人觉得单表查询已经足够用了，无非就是写写SELECT、WHERE、ORDER BY，顶多再来个GROUP BY做点统计。但真到业务落地，你会发现数据结构几乎不可能塞进一张大表里，订单、用户、商品、库存、支付流水各在各处，查询结果却需要把它们串在一起呈现。这时候就绕不开一个词：mysql 多表查询。这篇博文我不谈安装配置，也不讲备份恢复，就聚焦“多表查询”这一个点，把我这些年实际踩过的坑、用顺手的写法、排查慢SQL的思路全部摊开来讲。无论你是刚写完第一句JOIN的新手，还是被线上慢查询折磨过的老开发，这篇内容应该都能让你少走几步弯路。

1. 先把多表查询的底摸清楚

1.1 为什么会需要“多表查询”

要理解多表查询，先得理解关系型数据库为什么要把数据拆开。举一个最常用的例子：订单表里存了用户ID，用户表里存了用户昵称，如果每次查订单都要把用户昵称直接冗余到订单表里，那用户改名的时候就得同步改一堆历史订单，数据一致性问题接踵而来。所以设计上会把不同职责的数据拆分到不同表里，通过主键外键建立关联，这是第三范式的核心思路。

但拆分之后，查询需求却是“组合”的。比如后台要展示一个订单列表，列里有下单用户昵称、商品名称、订单金额、支付状态，这些字段分散在至少四张表里。单表查询只能拿到其中一部分，剩下的要么靠程序里多次查询拼接，要么就用一条JOIN把多张表关联起来一把梭。多表查询存在的意义，就是把这个“拆分-重组”的过程交给数据库引擎来做，让应用层代码更简洁、逻辑更清晰。

1.2 表之间关系的本质

写多表查询之前，先搞清楚表之间的关系，这决定了你该用哪种JOIN、怎么写连接条件。表关系主要有三种：

• 一对一：比如用户表与用户详情表，一个用户对应一条详情记录，通常通过相同的主键ID关联。
• 一对多：比如用户表与订单表，一个用户有多笔订单，订单表里存user_id，这就是最最常见的关系，左连接和内连接都经常在这种场景下使用。
• 多对多：比如商品表与标签表，一个商品有多个标签，一个标签对应多个商品，需要通过中间表关联，这时候经常要连续JOIN两张表，再加一个中间表。

我见过不少新手在写SQL时连表关系都没捋清楚，上来就直接JOIN，结果条件写错、数据翻倍、结果对不上。比如用户表和订单表一对多关联时，如果忘记了订单表里一个用户可能有多条记录，左连接后同一个用户会被重复出现多次，这不是查询“出错”了，而是你选择的连接方式本身就带有“放大行数”的特性。

1.3 连接查询的“地基”：笛卡尔积

不管什么JOIN，底层都可以理解为先在内存里做一次笛卡尔积，再用连接条件过滤出符合条件的行。笛卡尔积是什么？就是左表的每一行与右表的每一行组合一遍。用户表有100行，订单表有1000行，笛卡尔积就是10万行。

所以你在写连接查询的时候，连接条件（ON）绝对不能少。没有ON的JOIN在MySQL里会被当成CROSS JOIN处理，直接产出全量笛卡尔积。很多“查询卡死”“返回百万行垃圾数据”的故障，就是漏了ON条件导致的。另外要注意ON和WHERE的执行顺序：数据库引擎会先用ON条件过滤连接生成的结果集，再在这个结果集上应用WHERE过滤。理解这个顺序，有助于排查“为什么加了WHERE之后返回行数和预期不符”的问题。

2. 五种常用连接查询，我到底该用哪个

2.1 INNER JOIN：内连接，只取交集

内连接是多表查询里最常用的方式，也是很多人口中默认的“Join”。它只返回左表和右表中满足连接条件的行，两边都没有匹配的记录会被丢弃。

SELECT o.order_id, u.user_name, o.order_amount FROM t_order o INNER JOIN t_user u ON o.user_id = u.user_id;

这条SQL只返回有有效用户信息的订单。比如某个订单由于数据异常，user_id在用户表里找不到对应记录，这条订单就不会出现在查询结果中。这里有个实用心得：写INNER JOIN时，连接条件里的字段一定尽量用小表驱动大表，虽然MySQL的优化器大部分时候会自动选择驱动顺序，但多表连接时第一张表的选择会影响整体执行计划，尽早过滤掉无效数据能让后面的连接更轻快。

如果你发现INNER JOIN的结果和你预期对不上，先检查是不是右表有重复记录。比如订单表和订单明细表关联时，一个订单对应多条明细，这时INNER JOIN会把订单信息重复多行，如果需要“每个订单一行且带明细条数”，就得用GROUP BY配合聚合函数来做。

2.2 LEFT JOIN 与 RIGHT JOIN：一侧保底，另一侧可能为NULL

LEFT JOIN（左连接）在日常业务中出场率极高，比如“查所有用户以及他们的最近一笔订单”，这类需求必须把没有订单的用户也显示出来。

SELECT u.user_id, u.user_name, o.order_id, o.order_amount FROM t_user u LEFT JOIN t_order o ON o.user_id = u.user_id;

这里的语义是：左表（t_user）的记录全部保留，右表（t_order）只取匹配上的行，如果右表没有匹配记录，就用NULL填充。用这种方式展示用户列表时，即使新用户从未下过单，也能出现在列表中，只是订单字段为NULL。

RIGHT JOIN与LEFT JOIN方向相反，右表全保留，左表补NULL。说句实在话，我在真实项目中右侧连接用得相对较少，大家普遍习惯把“主表”写在左边，用LEFT JOIN来表达。如果你想用的语义是“右表全保留”，也可以把表的顺序换个方向改用LEFT JOIN，这样读起来更自然，也方便后续维护。

2.3 FULL JOIN：MySQL没有，但可以用UNION拼

FULL OUTER JOIN（全外连接）会返回左表和右表的全部记录，匹配不上的两侧都以NULL补齐。标准SQL里这个能力很常见，但MySQL至今没有原生实现FULL JOIN。好在我们可以用UNION把LEFT JOIN和RIGHT JOIN的结果合并起来，实现同样的效果。

SELECT u.user_id, u.user_name, o.order_id FROM t_user u LEFT JOIN t_order o ON o.user_id = u.user_id UNION SELECT u.user_id, u.user_name, o.order_id FROM t_user u RIGHT JOIN t_order o ON o.user_id = u.user_id;

UNION默认会去重，如果要保留重复行，可以改成UNION ALL。实际业务里“全外连接”的使用场景不算多，多半出现在数据对比、对账这类场景里，比如找出“在用户表里但不在订单表里”和“在订单表里但不在用户表里”的所有记录。用UNION组合时要注意两边查询的列数和数据类型必须一致，否则会报错。

2.4 CROSS JOIN：返回笛卡尔积的“重武器”

CROSS JOIN就是不带ON条件的连接，返回笛卡尔积。日常业务中几乎用不到，但它在某些场景下特别有用：比如要生成一段日期范围内的每一天，时间维度表不足时，可以用一个日期起始表和一个数字序列表做CROSS JOIN来补齐；再比如商品规格组合时，颜色表和尺码表做CROSS JOIN生成全部SKU组合。

SELECT c.color_name, s.size_name FROM t_color c CROSS JOIN t_size s;

使用CROSS JOIN时务必确认自己清楚结果集有多大。两个一万行的表CROSS JOIN后就是一亿行，在线上库这么干，轻则拖垮查询，重则把临时空间打爆，所以一定要慎用。补充一句，实际引擎在执行时不一定真的物理生成全量笛卡尔积再过滤，MySQL优化器通常会做条件下推优化，但作为开发者，理解这一层的逻辑仍然非常重要。

下面用一张表快速对比这几种连接：

3. 多表查询的进阶玩法

3.1 子查询与派生表：写SQL的“组合拳”

除了直接JOIN，多表查询还有一种常见的形态就是子查询。子查询可以在SELECT、FROM、WHERE三个位置使用，刚入门时可以优先用WHERE子查询理解逻辑，方便先看结果，再参与外层过滤。

一个很常见的需求是“筛选出下单金额超过平均值的用户”。如果先算平均值，再查用户，需要两步；用子查询一步搞定：

SELECT user_id, user_name FROM t_user WHERE user_id IN ( SELECT user_id FROM t_order GROUP BY user_id HAVING SUM(order_amount) > (SELECT AVG(order_amount) FROM t_order) );

这里用了两层子查询，内层算平均值，外层算每个用户的总金额并过滤。关于子查询的性能，我想多说一句：MySQL早期版本对“WHERE IN (子查询)”的优化不算友好，很多时候会逐行执行子查询；5.6以后的优化器改进了不少，会自动做半连接优化（semi-join），把IN子查询改写成连接方式执行。但从维护性来说，把复杂的子查询放到FROM里作为派生表（Derived Table），配合JOIN和WHERE，逻辑通常更清晰：

SELECT u.user_id, u.user_name, tmp.total_amount FROM t_user u INNER JOIN ( SELECT user_id, SUM(order_amount) AS total_amount FROM t_order GROUP BY user_id ) tmp ON u.user_id = tmp.user_id WHERE tmp.total_amount > 100;

这种写法的优点是先聚合后关联，结果集更小，连接时的开销也更小。习惯上，如果子查询需要在外部多次引用，派生表会更合适；如果只是单纯判断“是否存在”，用EXISTS往往比IN更快。

3.2 GROUP BY + JOIN：多表统计的正确姿势

多表JOIN后做统计，是报表类业务的家常便饭。最常见的坑是：不加DISTINCT直接COUNT，导致数据重复；或者分组字段没写全，被SQL模式中的ONLY_FULL_GROUP_BY卡住报错。

先看一个典型需求：统计每个用户的订单数和总金额，且用户必须来自VIP用户表。

SELECT u.user_id, u.user_name, COUNT(o.order_id) AS order_cnt, IFNULL(SUM(o.order_amount), 0) AS total_amount FROM t_vip_user v INNER JOIN t_user u ON v.user_id = u.user_id LEFT JOIN t_order o ON u.user_id = o.user_id GROUP BY u.user_id, u.user_name;

这里有几个细节值得注意。第一，COUNT里我写的是o.order_id，而不是COUNT()，目的就是避免LEFT JOIN时因右表没有匹配行而把NULL也数进去，COUNT(字段)不统计NULL值，而COUNT()会把NULL行也统计到。第二，SUM外面包了IFNULL，因为左连接没匹配时SUM的结果是NULL，展示为0在报表里更友好。第三，分组时我GROUP BY了u.user_id和u.user_name两个字段，如果只分组user_id，在ONLY_FULL_GROUP_BY模式下会直接报错。

顺带提一下ONLY_FULL_GROUP_BY。MySQL 5.7以后默认开启了sql_mode=ONLY_FULL_GROUP_BY，这导致“SELECT非聚合字段但不参与GROUP BY”的写法会直接被拒绝。很多人第一次遇到这个报错时一脸懵，解决方案有两个：最推荐的是把所有“SELECT出来的非聚合列”都加到GROUP BY里；如果确实需要某一列的值且该列在分组内是唯一的，可以借助ANY_VALUE()函数绕过去，但不建议滥用。

3.3 UNION与UNION ALL：多个结果集的“拼图”

JOIN是横向扩展列，UNION是纵向扩展行。UNION可以把两条独立的查询结果堆叠在一起，前提是两条查询的列数一致、数据类型匹配。

实际业务里常见场景：电商后台要展示“下单用户+注册未下单用户”的组合列表，或者查询两张结构相同的分表数据。分表场景下，UNION ALL几乎是必用的：

SELECT order_id, order_amount, create_time FROM t_order_2024 WHERE create_time BETWEEN '2024-01-01' AND '2024-06-30' UNION ALL SELECT order_id, order_amount, create_time FROM t_order_2025 WHERE create_time BETWEEN '2025-01-01' AND '2025-06-30';

用UNION ALL时会保留重复行，UNION默认去重。去重不是免费的，去重会额外执行一次排序或哈希操作，数据量大时性能开销很明显。所以如果你确定两条查询之间没有重复数据，或者重复数据不影响业务，就直接用UNION ALL，性能差好几倍。

还有一个细节：UNION里各段查询的ORDER BY建议放到最后一段查询之后统一排序，否则中间段的ORDER BY可能被优化器忽略。要排序就整体排序，不要在每个子段里分开排序。

3.4 关联查询与去重问题

多表JOIN之后出现重复数据，这是我被问最多的问题之一。比如商品表关联标签表时，一个商品有三个标签，查询商品信息时商品就会变三行。有人第一反应是给SELECT加上DISTINCT，但很多时候DISTINCT解决不了问题，反而掩盖了逻辑漏洞。

举一个典型的反例：

SELECT DISTINCT p.product_id, p.product_name, t.tag_name FROM t_product p INNER JOIN t_product_tag_relation r ON p.product_id = r.product_id INNER JOIN t_tag t ON r.tag_id = t.tag_id;

这里DISTINCT的作用范围是整个三列组合，如果一个产品有“热销”“新品”两个标签，即便只有这一个产品，查询结果也会有两行，DISTINCT完全没用。正确做法是：先想清楚业务到底要的是“每个商品一行，标签拼接成一个字段”，还是“每个商品多行展示标签信息”。如果是前者，可以用GROUP_CONCAT把标签聚合到一个字段里：

SELECT p.product_id, p.product_name, GROUP_CONCAT(t.tag_name SEPARATOR ',') AS tag_names FROM t_product p LEFT JOIN t_product_tag_relation r ON p.product_id = r.product_id LEFT JOIN t_tag t ON r.tag_id = t.tag_id GROUP BY p.product_id, p.product_name;

这里用LEFT JOIN而不是INNER JOIN，是为了避免没有标签的商品被过滤掉。GROUP_CONCAT默认最多返回1024字节，标签很多时可以调大group_concat_max_len参数。

4. 多表查询的性能调优与排查技巧

4.1 告别慢查询：EXPLAIN只看这四列

多表查询性能差，九成以上和索引有关。先记住一个核心检查习惯：拿一条慢SQL先跑EXPLAIN，不要猜。

EXPLAIN SELECT u.user_name, o.order_amount FROM t_order o INNER JOIN t_user u ON o.user_id = u.user_id WHERE o.create_time >= '2025-01-01';

输出结果里重点看四列：

• type：连接类型，从好到差依次是system > const > eq_ref > ref > range > index > ALL。出现ALL就是全表扫描，需要警惕。
• key：实际用到的索引名，是NULL说明没用到索引。
• rows：预估扫描的行数，越小越好。多表连接时各表的rows差距不能太离谱。
• Extra：出现了Using filesort或者Using temporary，往往意味着排序或分组无法利用索引，需要看是否可以通过调整索引或SQL写法优化。

实际调优时，连接字段必须是索引列，这是最基本的。比如上面SQL中，t_order.user_id和t_user.user_id都应有索引。如果关联字段没有索引，MySQL就会用嵌套循环去逐行匹配，复杂度直接拉满。如果是LEFT JOIN，被驱动表（右表）的连接字段上加索引通常更有效。

4.2 驱动表与被驱动表的大小关系

多表连接时，“驱动表”决定遍历从哪边开始，“被驱动表”决定每遍历一行时要到哪边去查找。合理情况下，驱动表应该尽量小，被驱动表的连接字段必须有索引。这样每个驱动表的行去命中被驱动表时，都能走索引快速定位，整体代价大约等于“驱动表行数 * 被驱动表索引查找代价”。

MySQL优化器在很多情况下会自动选择小表作为驱动表，但有一些写法会影响它的判断。比如WHERE条件里对驱动表加了函数运算：

SELECT ... FROM t_order o INNER JOIN t_user u ON o.user_id = u.user_id WHERE DATE_FORMAT(o.create_time, '%Y-%m-%d') = '2025-06-01';

这里对create_time用DATE_FORMAT包装后，即使create_time上有索引，因为函数破坏了索引有序性，也无法走索引范围扫描。改成WHERE o.create_time >= '2025-06-01' AND o.create_time < '2025-06-02'就能充分利用索引。

4.3 三种JOIN算法与索引的关系

MySQL常用的JOIN算法主要有三种：

• Nested Loop Join（嵌套循环连接）：最传统的算法，驱动表每取一行，就到被驱动表做一次索引查找。如果被驱动表连接字段无索引，每行都要全表扫，代价巨大。
• Block Nested Loop Join（块嵌套循环连接）：当被驱动表无索引时，MySQL会把驱动表的部分数据缓存到join_buffer，然后一次性与被驱动表的多行做比较，减少被驱动表扫描次数。这类算法在Extra里显示为“Using join buffer (Block Nested Loop)”。看到这个提示，基本说明被驱动表关联字段没有索引，需要补索引。
• Hash Join（哈希连接）：MySQL 8.0引入，适用于等值连接且被驱动表无索引的场景。它先把驱动表构建成哈希表，再扫描被驱动表去做匹配，效率比块嵌套循环高不少。但对于大多数OLTP场景，给连接字段加索引是最常规的路子，Hash Join更多地用于分析、报表场景。

实际工程里有一条很实用的经验法则：小表驱动大表，连接字段建索引，避免在连接字段上做类型转换和函数运算。做到了这三点，绝大多数多表查询的慢问题都能解决。

4.4 大表JOIN的替代思路

不是所有多表查询都能靠索引救回来。当千万级大表JOIN千万级大表时，即使索引齐全，查询也未必快。这个时候可以甩出几个替代方案：

• 冗余字段：如果某条业务数据被高频查询且低频修改，直接在表里冗余一个字段，比如订单表里冗余用户昵称，避免每次都要JOIN用户表。
• 汇总表：报表类查询可以把明细数据按天/按小时汇总到统计表，查询时直接查汇总表，避免大表关联明细。
• 分库分表：如果业务量级实在太大，单库单表扛不住，那就要考虑从架构层面做拆分，数据库层面的JOIN降级为应用层手动拼接。这种方式最彻底，但也最复杂，通常不是第一选择。

我做过一个真实项目，订单表和商品快照表都是近千万级数据，为了一个“历史订单详情列表”天天被慢查询投诉。后来把查询需求拆成了两步：先查订单表主记录，再根据订单ID批量查商品快照，代码里做拼接。整体耗时从原来的5秒降到了200毫秒左右。应用层拼接不一定比SQL JOIN差，有时候反而更可控。

5. 日常开发中那些必踩的坑

5.1 连接条件里的NULL陷阱

多表查询最容易出问题的地方，就是NULL值。比如用户表和订单表用user_id关联，订单表里某些历史数据user_id是NULL，那么INNER JOIN时这些订单永远匹配不上用户；LEFT JOIN时这些订单会保留下来，但用户字段为NULL。

更隐蔽的是连接条件里的等值判断：

SELECT u.user_name, o.order_id FROM t_user u LEFT JOIN t_order o ON o.user_id = u.user_id AND o.order_status = 1;

这里如果把o.order_status = 1从ON挪到WHERE里，语义完全变了。放在ON里，它只影响右表匹配；放在WHERE里，它会过滤掉所有不满足条件的行，包括那些原本因为左连接而保留的NULL行。很多同事在这个地方翻过车，查出来的用户少了一批，还找不到原因。记住：LEFT JOIN时，对右表的过滤条件放到ON里，对最终结果集的全局过滤放到WHERE里。

5.2 关联字段类型不一致引发索引失效

这是最隐蔽的坑。比如订单表的user_id是varchar类型，用户表的user_id是bigint类型，关联时MySQL会对varchar做隐式类型转换，导致用户表上的索引失效，驱动表每一行都去全表扫描用户表，SQL瞬间变慢。

排查方法很简单：EXPLAIN看type列，如果被驱动表的type是ALL，基本就是关联字段类型不一致或者索引没建上。修复方案也明确：统一关联字段类型，或者在SQL里显式把类型CAST成一致再关联。但彻底的做法是修改表结构，从源头统一类型，不要在SQL里打补丁。

5.3 同一张表多次JOIN，必须起别名

如果一张表要关联多次，比如订单表里既有下单用户又有审核用户，需要JOIN两次用户表：

SELECT o.order_id, u1.user_name AS creator_name, u2.user_name AS auditor_name FROM t_order o LEFT JOIN t_user u1 ON o.create_user_id = u1.user_id LEFT JOIN t_user u2 ON o.audit_user_id = u2.user_id;

不加别名的话，MySQL会直接报“Not unique table/alias”错误。这是个好习惯，任何多表查询里，每张表只要出现一次以上，就必须用别名区分。即使只出现一次，也建议习惯性加别名，后续改SQL时你会感谢这个习惯。

5.4 排序与分页中的数据错乱

多表JOIN后配合ORDER BY和LIMIT，要注意分页数据是否稳定。JOIN之后结果集因为一对多关系出现大量重复行，排序字段的值又是同一张表的列，这时分页可能出现前后页数据“跳跃”或“重复”。

一种常见现象：用户表LEFT JOIN订单表，按订单创建时间排序。用户A有三笔订单，用户B有两笔订单，结果集的行数为两者之和。如果LIMIT 10，第一页刚好取到用户A的部分订单、第二页又从用户A的另一个订单开始，用户B可能始终排不上。解决办法是先按业务维度（比如用户）聚合排序，再做分页；或者用窗口函数固定分组排序逻辑，但这类写法更适合报表场景，日常联机查询尽量保持排序维度唯一。

5.5 sql_mode=ONLY_FULL_GROUP_BY 报错处理

MySQL 5.7及以上版本默认开启ONLY_FULL_GROUP_BY，意味着SELECT的列要么在GROUP BY中出现，要么在聚合函数中。很多从5.6或5.5时代迁移过来的老SQL会突然报这个错：

Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column

处理路径有两条：第一条是改SQL，把非聚合列补进GROUP BY，推荐；第二条是在sql_mode中移掉ONLY_FULL_GROUP_BY，比如通过SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''))，但这种方式在生产环境不建议，因为它降低了SQL规范性，而且新同事写SQL时不会意识到这个限制，上线后问题更难查。短期的兼容可以改参数，长期的一定要改SQL。

6. 一个综合案例：电商后台订单列表的多表查询

最后用一个完整的案例把这些知识点串起来。需求是：电商后台按条件分页查询订单列表，展示列包括订单号、下单用户昵称、收货人姓名、商品总金额、订单状态、下单时间，并支持按照用户昵称模糊搜索、按下单时间倒序排列。涉及的表：t_order（订单主表）、t_user（用户表）、t_user_address（地址表）。

首先明确关系：订单表一对多关联用户表和地址表，但这里只需要用户昵称和收货地址中的收货人姓名，直接用LEFT JOIN关联两张辅助表即可：

SELECT o.order_id, u.user_name, a.receiver_name, o.order_amount, o.order_status, o.create_time FROM t_order o LEFT JOIN t_user u ON o.user_id = u.user_id LEFT JOIN t_user_address a ON o.address_id = a.address_id WHERE u.user_name LIKE CONCAT('%', '张', '%') ORDER BY o.create_time DESC LIMIT 20 OFFSET 0;

这个查询看起来不复杂，但有一些性能细节需要注意：

• LIMIT深分页：如果用户翻到第10000条之后，比如LIMIT 20 OFFSET 100000，MySQL会先扫描100020行再丢掉前10万行，越翻越慢。优化方式是记录上一页最后一条数据的create_time，改用WHERE o.create_time < :lastCreateTime ORDER BY create_time DESC LIMIT 20，也就是“游标分页”。
• 字段覆盖：查询结果需要的字段都在各自主表里，没有多余的表参与JOIN，这就避免了不必要的连接开销。
• 索引设计：这个SQL的WHERE条件里有user_name的LIKE模糊匹配，左侧有通配符时无法走索引，只能全表扫用户表再关联。如果用户量很大，建议考虑引入搜索引擎，但中小体量下MySQL也能扛住，这个查询重点还是要保证t_order.user_id和t_order.address_id上有索引，而t_order.create_time上的索引用于排序。

当然，很多业务还会加上“订单状态”“下单时间范围”等过滤条件，这要结合具体场景，原则是过滤性强的条件优先、排序字段尽量走索引。如果过滤条件组合特别多，可以考虑建联合索引，但不要一个条件一个索引，那会导致优化器难以选择。

7. 快速排查指南：一张表帮你定位多表查询问题

多表查询报错或者结果不对，别急着改SQL，先做个系统排查。下面是我总结的排查路径，可以按顺序过一遍：

这个表相当于一个速查手册，遇到问题先对照定位，大多数都能在十分钟内解决。

个人经验小灶

从工作到现在，我写过也优化过非常多多表查询的SQL。一个很深的体会是：多表查询的核心，永远是先想清楚业务要什么，再想表怎么关联，最后才是写SQL语法。顺序搞反了，经常写出“跑得动但结果错”“结果对但慢到离谱”的SQL。

最后补几个我长期坚持的实操习惯，送给看到这里的读者。第一，所有多表查询的语句，手写之前先花三十秒理清表关系，画张草图画一下也无妨。第二，写完SQL先跑EXPLAIN，扫一眼type、key、rows，这三个值健康了再往线上放。第三，给查询涉及到的关联字段、WHERE字段、ORDER BY字段建联合索引时，不要贪多，联合索引里字段顺序遵循“等值查询字段在前、范围查询字段在后”的原则，这是无数经验换来的教训。第四，遇到LEFT JOIN结果数量异常，先检查ON和WHERE条件是不是混用了，这是多表查询里最经典也最坑的问题，没有之一。

多表查询这东西，看着简单，但真正写出“稳准快”的SQL，需要的就是这些细节上的积累。希望这篇内容能帮你少踩几个坑。