前两天和一个做数据分析的朋友吃饭，聊到他们公司新来的实习生写SQL查数据，左连接居然写成了内连接，结果报表数据对不上，被领导骂了一顿。这种事在职场里太常见了，我见过很多人，包括一些工作两三年的开发，对左连接的理解还停留在“左边表的数据都要”这个层面。说得对也对，但远远不够。
左连接（LEFT JOIN）看起来简单，但真正用好的时候能救你很多次。比如你有一张订单表，记录了所有订单，但有些订单还没有发货，发货表里可能没有对应的记录。这时如果用了内连接，那些未发货的订单就全丢了。左连接的好处是，它会保留左表的所有记录，右边表没有匹配上的字段就补 NULL。这就像去朋友家串门，朋友家的人都要算上，哪怕有人不在家，你也要在名单上留个位置。
左连接有个坑，很多人踩过。当左表的多条记录匹配右表时，结果会出现重复行。我有个同事做报表，左连接后数据量翻了好几倍，排查了三个小时才发现是右表里存在重复的关联字段。这种情况很常见，比如一个用户有多个地址，你左连接地址表时，每个用户就会变成多行。解决办法不难，要么提前去重，要么用子查询先处理右表。左连接不是无脑连接，而是要有策略地去连。
说到策略，左连接在实际业务中往往不是单独使用，而是多个左连接叠加。比如查询订单详情，可能需要左连接用户表、商品表、物流表、支付表。这时顺序就很重要。一般来说，数据量大的表放左边，数据量小的表放右边，SQL 执行效率会更高。我见过有人把几十万行的订单表和上百万行的日志表左连接，结果跑了五分钟才出结果。把顺序调换，日志表放左边，订单表放右边，十几秒就出来了。
还有一个容易被忽视的点，就是左连接后的过滤条件。很多人习惯在 WHERE 里加右表的字段，例如 ，看似没问题，但实际会把左连接变成内连接。因为左连接会保留左表所有记录，但如果右表没有匹配上，status 为 NULL，NULL 不等于 1，这些记录会被 WHERE 过滤掉。正确做法是把条件写在 ON 子句里，例如 。
左连接和右连接是一对镜像关系，但实际工作中左连接用得更多。原因很简单：大多数人习惯把主表放左边，子表放右边。比如查询用户信息，用户表是主表，订单表是子表，就把用户表放左边，左连接订单表。右连接也能实现同样效果，但写法上不太符合直觉。我建议除非特殊情况，统一使用左连接，团队协作时别人看你的 SQL 更清晰。
在性能优化上，左连接有一个关键点——关联字段一定要建索引。没有索引的左连接，就像在一本没有目录的书里找词，只能一页一页翻。建了索引，就像有了目录，直接定位到对应页。我见过一个查询，左连接两个十万行的表，没建索引跑了 8 秒，建了索引后不到 0.1 秒。索引的字段类型也要注意，字符集不一致会导致索引失效，例如左表是 utf8，右表是 utf8mb4，连接时 MySQL 会做隐式转换，索引就用不上了。
左连接还有一个高阶用法，就是做数据补全。比如需要生成连续日期的报表，可以先生成一个日期主表，再用左连接关联业务表，没有数据的日期就补 0。这种方法在金融、电商的日报表场景里特别实用。我有个朋友做电商运营，每天要拉近 30 天的销售趋势，用左连接补全空值后，图表看起来就平滑了，领导看着也舒服。
说了这么多，左连接的核心其实一句话：保留左表全部记录，右表匹配不上就补 NULL。但这句话背后涉及的索引、过滤条件、重复数据处理、多表连接顺序，每一个细节都能决定你的 SQL 是优雅高效还是又慢又错。写 SQL 就像写文章，左连接就是那个标点符号，看似简单，用好了才能让整个语句通顺流畅。下次写左连接前，不妨先想清楚：我要保留下哪些数据？右表有没有重复？过滤条件写在哪里？关联字段有没有索引？这些想清楚了，再敲回车。
