复合主键JOIN必须显式写出所有主键字段，漏写会导致数据膨胀或失真；需校验字段名、数量、类型、NULL性及字符集，并在ON中完整匹配，避免隐式转换和NULL过滤问题。
复合主键JOIN必须显式写出所有主键字段
漏掉任何一个字段，结果不是空，就是爆炸——比如 100 行订单变成 5000 行。数据库不会报错，但数据已失真。orders 表主键是 (customer_id, order_date)，你只写 ON o.customer_id = c.id，那同客户不同日期的订单全被压到同一行，时间维度彻底丢失。
- 先查清主键定义：
SHOW CREATE TABLE orders或查INFORMATION_SCHEMA.KEY_COLUMN_USAGE - ON 子句里必须一一对应所有主键字段，顺序无关，但字段名、数量、类型一个都不能少
- 别用
USING：它要求两边字段名完全一致，而order_date和cust_reg_date这类命名差异很常见
字段类型不一致会让JOIN“静默失效”
MySQL 可能隐式转换但丢索引，PostgreSQL 直接报 operator does not exist。比如 orders.customer_id 是 VARCHAR(32)（存 UUID），而 customers.id 是 CHAR(36)，末尾空格或大小写比较规则不同，匹配就断了。
- 用
DESCRIBE orders和DESCRIBE customers对比字段类型，包括是否NOT NULL、字符集、COLLATION - 类型不同时加显式转换：
ON CAST(o.customer_id AS TEXT) = c.id（PostgreSQL）或ON CONVERT(o.customer_id, CHAR) = c.id（MySQL） - 建表时就对齐：UUID 类主键统一用
VARCHAR(36)，避免后期补救
NULL值会让等值条件直接跳过匹配
ON o.customer_id = c.id AND o.order_date = c.reg_date 中任一字段为 NULL，整行就不参与连接——不是报错，而是无声消失。查不到数据时，先跑一遍 SELECT COUNT(*) FROM orders WHERE customer_id IS NULL OR order_date IS NULL。
- 业务允许的话，JOIN 前过滤：
WHERE o.customer_id IS NOT NULL AND o.order_date IS NOT NULL - 需要保留 NULL 行？改用
COALESCE(o.customer_id, '') = COALESCE(c.id, '')，但得确认空字符串在业务上是否等价 - 更稳妥的做法：提前清洗，把
NULL替换成业务可识别的占位值（如'UNKNOWN'），并在外键字段加NOT NULL约束
LEFT JOIN + 复合主键时，右表筛选条件必须写在ON里
写成 LEFT JOIN customers c ON o.customer_id = c.id AND o.order_date = c.reg_date WHERE c.status = 'active'，效果等同于 INNER JOIN——所有 c.status 为 NULL 的订单行全被干掉。
- 正确写法：
LEFT JOIN customers c ON o.customer_id = c.id AND o.order_date = c.reg_date AND c.status = 'active' - 如果条件复杂（比如要关联多个状态），优先考虑用
EXISTS替代：AND EXISTS (SELECT 1 FROM customers c2 WHERE c2.id = o.customer_id AND c2.reg_date = o.order_date AND c2.status = 'active') - EXISTS 天然规避复合主键字段缺失、NULL 传播、类型隐式转换等问题，语义也更贴近“是否存在匹配”
order_date 字段其实有 3% 是 NULL。上线前务必用 GROUP BY 检查膨胀：SELECT customer_id, order_date, COUNT(*) FROM orders GROUP BY customer_id, order_date HAVING COUNT(*) > 1 —— 如果有结果，说明主键定义和实际数据不一致，这时候再写 JOIN 已经晚了。 
