单表查询跑顺以后，多表查询很快就会出现。业务接口里很少只有一张表：用户要带订单，订单要带支付，统计时还要按用户、状态、时间分组。join 这几个字本身不难，真正容易出问题的是结果行到底从哪张表开始保留，哪些字段会被补成 NULL，条件放在 on 里还是放在 where 里，以及统计时到底数的是用户、订单，还是连接后的结果行。

从 MySQL 切到 KingbaseES，不需要一上来就追复杂场景。先用三张小表把结果边界跑清楚，比背一串 JOIN 类型更有用。

结果只有 4 行。alice 出现两次，对应订单 101 和 102；bob 对应订单 103；cindy 对应订单 104。david、eric 没有订单，不返回。订单 105 的 user_id 是 6，用户表里找不到，也不返回。

这就是 inner join 最朴素的规则：两边都能连上，才进入结果集。一对多关系会把主表行展开，alice 在用户表里只有一行，连订单以后变成两行。后面做统计时，这个展开会直接影响 count(*) 的结果。

内连接适合回答“已经发生关联的记录有哪些”。比如只关心有订单的用户、只关心能找到用户的订单，inner join 很干净。但如果接口要查用户列表，再顺带展示订单信息，用内连接就会把没有订单的用户吞掉。SQL 没报错，页面上少了人，这种问题比语法错误更隐蔽。

LEFT JOIN 会保留左表

如果要查所有用户，以及用户有没有订单，内连接就不够了。换成左连接：

select
  u.user_id,
  u.user_name,
  u.status,
  o.order_id,
  o.order_status,
  o.amount
from app_schema.t_join_user u
left join app_schema.t_join_order o
  on u.user_id = o.user_id
order by u.user_id, o.order_id;

这次返回 6 行。alice 仍然因为两笔订单出现两次；bob、cindy 各一行；david、eric 虽然没有订单，也被保留下来，只是订单相关字段为空。订单 105 不会出现，因为这条 SQL 的左表是用户表。

这个结果比定义更好记：从用户表出发，用户不会丢；订单能匹配就带出来，匹配不到就补 NULL。很多列表页、后台管理页、报表底表都会用到这种写法。

这里的 NULL 也要当成结果的一部分看。david、eric 的订单字段为空，并不表示查错了，恰好说明“用户存在，但没有匹配订单”。如果后面接 Java 代码、MyBatis 映射或者接口 JSON，右表字段要允许为空。把这些 NULL 又强行转成默认对象，很容易让调用方误以为真的有一笔空订单。

条件放 ON 里，和放 WHERE 里不是一回事

外连接最容易写错的地方，不是 left join 本身，而是右表条件放在哪里。

先把订单状态条件放在 on 里：

from app_schema.t_join_user u
left join app_schema.t_join_order o
  on u.user_id = o.user_id
 and o.order_status = 'paid'

结果只剩 2 行：alice 的 101 和 bob 的 103。没有已支付订单的用户都被过滤掉了。

这一步在真实开发里很常见。需求说“查所有用户，并展示已支付订单”，条件应该放在 on 里；需求说“只查有已支付订单的用户”，条件放在 where 里更直接。两个 SQL 看起来只差一行位置，结果从 5 行变成 2 行。

不要把它粗暴记成某个固定口诀。直接看执行后的结果更稳：on 控制右表怎么匹配，where 会对连接后的结果再过滤。右表字段为 NULL 的那些行，遇到 where o.order_status = 'paid' 自然留不下来。

这个差别在订单状态筛选里尤其明显。需求如果写的是“所有用户都要展示，只看他们的已支付订单”，用 on 更符合语义；需求如果写的是“只展示有已支付订单的用户”，用 where 更符合语义。同样都是 paid，业务语义不一样，SQL 位置就不一样。写之前先把这句话问清楚，比写完再看结果少很多返工。

RIGHT JOIN 和 FULL JOIN 看边界更直观

right join 可以从订单表角度看用户匹配情况：

结果返回 7 行。匹配成功的 4 行正常出现；david、eric 作为只有用户、没有订单的数据保留下来；订单 105 作为只有订单、没有用户的数据也保留下来。

MySQL 用户平时更常写 left join，right join 换个方向也能理解。full join 值得单独跑一下，因为它能同时看两边不匹配的数据。做数据核对时，这种结果很直观：哪边缺了，NULL 就出现在另一边。

right join 在日常代码里不一定非用不可。很多团队会把右连接改写成左连接，只是为了让主表从左往右读起来更顺。full join 的用途更偏核对和排查，它不是每个列表接口都需要，但遇到“两边都可能有孤立数据”的场景时，比把两个左连接结果再拼起来更直接。

三表 LEFT JOIN 会受出发点影响

再把支付表连进来：

select
  u.user_id,
  u.user_name,
  o.order_id,
  o.order_status,
  o.amount,
  p.payment_id,
  p.pay_status,
  p.pay_amount
from app_schema.t_join_user u
left join app_schema.t_join_order o
  on u.user_id = o.user_id
left join app_schema.t_join_payment p
  on o.order_id = p.order_id
order by u.user_id, o.order_id, p.payment_id;

select
  o.order_id as order_id_from_order,
  o.order_no,
  o.order_status,
  p.payment_id,
  p.order_id as order_id_from_payment,
  p.pay_status,
  p.pay_amount
from app_schema.t_join_order o
full join app_schema.t_join_payment p
  on o.order_id = p.order_id
order by coalesce(o.order_id, p.order_id), p.payment_id;

select
  u.user_id,
  u.user_name,
  count(*) as joined_rows,
  count(o.order_id) as order_count,
  count(case when o.order_status = 'paid' then 1 end) as paid_order_count,
  coalesce(sum(o.amount), 0) as total_amount
from app_schema.t_join_user u
left join app_schema.t_join_order o
  on u.user_id = o.user_id
group by u.user_id, u.user_name
order by u.user_id;

select
  count(*) as joined_rows,
  count(u.user_id) as user_id_count,
  count(distinct u.user_id) as distinct_user_count,
  count(o.order_id) as order_count
from app_schema.t_join_user u
left join app_schema.t_join_order o
  on u.user_id = o.user_id;

select
  u.user_id,
  u.user_name,
  u.status
from app_schema.t_join_user u
where exists (
  select 1
  from app_schema.t_join_order o
  where o.user_id = u.user_id
)
order by u.user_id;
​