SQL里的连接类型连接操作，说白了就是操作两张表怎么“拼”的问题。但拼法有好几种，连接类型选错了，操作轻则结果错，连接类型重则性能崩。操作

最常用的连接类型就是INNER JOIN，只留两边都匹配得上的操作行。拿订单表和用户表举例，连接类型你想看谁买了东西，操作INNER JOIN一上去，连接类型没下过单的操作用户自动消失。这玩意儿最直观，连接类型性能也最好，操作因为数据库能直接跳过不匹配的连接类型数据。我见过不少新手一上来就LEFT JOIN，哪怕业务上根本不需要保留空用户，结果查出来的行数莫名其妙多了一倍，排查半天才发现是JOIN条件写漏了。

LEFT JOIN和RIGHT JOIN是一对镜像。LEFT JOIN保留左表全部行，右表没有匹配就补NULL。这个用的场景太多了——比如你想统计每个用户的订单数，包括那些一个订单都没下过的“僵尸用户”，就必须LEFT JOIN。RIGHT JOIN其实不太常用，因为大部分人习惯把主表写在左边，写RIGHT JOIN反而别扭。真要用到了，多半是别人写好的SQL你接手，这时候把RIGHT JOIN改成LEFT JOIN换个表顺序，逻辑一模一样，但读起来顺眼得多。

FULL OUTER JOIN是最容易被忽略的。它把两边表的所有行都保留，匹配不上的补NULL。说实话，日常业务里用到它的频率极低，因为“两边都可能缺数据”的需求本身就少见。我一个做数据仓库的朋友说，他干了五年，FULL OUTER JOIN用过的次数一只手数得过来，而且每次都是在做数据对账——比如比对两个系统的用户差异，找出只在A系统存在、只在B系统存在、以及两边都存在的用户。这种场景下，它确实无可替代。

CROSS JOIN就更有意思了，它不带ON条件，直接做笛卡尔积。左表3行右表4行，结果就12行。这玩意儿看着简单，但实际开发中它经常以“事故”的形式出现——比如你忘了写JOIN条件，数据库就会默默给你做CROSS JOIN，数据量一大直接炸。不过它也有正经用途，比如生成日期维度表，拿年份和月份两个小表做交叉，几行代码就能拼出全年的日期。

还有一种容易混淆的，叫SELF JOIN，其实是同一张表跟自己做连接。比如员工表里有个字段叫manager_id，指向另一个员工的id，你想查出“谁管谁”，就得把员工表别名成两张表再JOIN。这玩意儿逻辑上不难，但写起来容易犯晕，尤其是别名一多，条件稍微写错就查出一堆莫名其妙的关系。

每种连接都有它存在的理由，但别迷信“功能全”就乱用。我见过有人为了偷懒，把LEFT JOIN当INNER JOIN用——反正结果集里那些NULL行业务上也不会去读。可这样干，数据库得先算出所有左表行，再过滤掉NULL，性能白白浪费一大截。连接类型的选择，本质上是业务需求和数据库执行计划之间的博弈。你心里得有数：这张表到底要不要保留空行？匹配关系是一对一还是一对多？搞清楚这两点，选起来就不纠结了。