left join 能保留联系人主表全部数据并透出 null 以定位断点，而 inner join 遇任一关联缺失即整行消失，导致漏查无订单线索或异常订单。
直接结论：用 LEFT JOIN 从联系人表出发，逐层关联订单、订单商品、产品、客户档案等表，才能保证“每个联系人都能查到其所有订单（含空）”，同时避免因中间表缺失导致整条链断裂。
为什么不能只用 INNER JOIN？
CRM 中常见数据不完整场景：联系人没下过单、订单被误删、订单商品记录丢失、产品已下架但订单仍存在。一旦用 INNER JOIN，只要某一层没匹配上，整行就消失——你查不到“没下单的销售线索”，也看不到“无商品信息的异常订单”。
例如：contacts → orders → order_items → products，若某个订单的 order_items 被清空，INNER JOIN 会让该订单在穿透查询中彻底不可见。
正确做法是：主表（contacts）做左表，后续每层都用 LEFT JOIN，让 NULL 可控地透出，便于定位数据断点。
LEFT JOIN 链式写法的关键顺序与别名管理
顺序决定可读性与调试效率。必须从核心业务实体开始，向附属表延伸：
- 第一层：以
contacts为起点（主表），别名设为c - 第二层：通过
c.contact_id = o.contact_id关联orders（别名o） - 第三层：通过
o.order_id = oi.order_id关联order_items（别名oi） - 第四层：通过
oi.product_id = p.product_id关联products（别名p）
错误示例：FROM orders o LEFT JOIN contacts c ON ... —— 这会把订单当主表，漏掉无订单的联系人；且别名混乱后，ON 条件极易写反字段方向。
如何识别并处理 NULL 值带来的聚合陷阱？
穿透后常需统计“每人订单数”“总金额”等，但 LEFT JOIN 会引入 NULL 行，直接 COUNT(*) 或 SUM() 会污染结果：
-
COUNT(o.order_id)统计有效订单数（NULL 不计入） -
SUM(COALESCE(oi.quantity * p.price, 0))避免因oi或p为 NULL 导致整列变 NULL - 慎用
GROUP BY c.contact_id后直接SELECT *—— 多层 LEFT JOIN 下，非分组字段（如p.product_name）可能有多个值或 NULL，数据库行为因引擎而异（MySQL 允许，PostgreSQL 报错）
真实业务中，contact_id = 123 可能对应 5 条订单，其中 2 条的 product_id 为空，此时 COALESCE(p.product_name, '[缺失]') 比裸写 p.product_name 更利于排查。
性能与索引必须同步考虑
四层 LEFT JOIN 在千万级联系人下极易慢，关键不在写法，而在索引是否覆盖连接路径：
-
contacts表必须有contact_id主键（默认有） -
orders表需在contact_id上建索引（不是主键时易遗漏） -
order_items表需联合索引(order_id, product_id)—— 单独order_id索引不够，因后续还要连products - 避免在
ON条件里用函数，如ON UPPER(c.email) = UPPER(o.email)，会导致索引失效
最常被忽略的一点：CRM 系统中，contacts 表常带软删除字段（如 is_deleted = 0），但很多人忘了在 WHERE 子句里加上这个过滤条件，导致逻辑删除的联系人仍参与 JOIN，拖慢速度且污染结果。
