INNER JOIN 仅在业务要求“两边数据必须同时存在”时使用，如查已下单且完成实名认证的订单；误用会导致未匹配数据丢失，如统计所有用户最近订单时漏掉无订单用户。
INNER JOIN 什么时候该用，什么时候不该用
当业务逻辑要求「两边数据必须同时存在」时才用 INNER JOIN。比如查「已下单且已完成实名认证的用户订单」，缺一不可——没下单的用户、没认证的订单都得被筛掉。
常见错误是拿它当默认选择：看到两个表就 INNER JOIN，结果漏掉大量未匹配数据。比如统计「所有用户最近一次订单金额」，若用 INNER JOIN，那些从没下过单的用户就彻底消失了，报表人数直接缩水。
- 适用场景：
user和order表关联查「有效订单归属」；权限校验中验证user_role和role_permission是否同时存在 - 不适用场景：用户画像补全（需保留无订单用户）、漏斗分析起始层（如「注册用户数」不能因没行为就被过滤）
- 性能影响：驱动表（左表）若有高基数但右表匹配率极低，可能触发大量无效哈希查找，比
LEFT JOIN更慢
LEFT JOIN 不等于“保左表”，关键看 ON 和 WHERE
LEFT JOIN 的结果集确实保留左表全部行，但真正决定哪些行最终出现的，是 WHERE 子句——很多人把过滤条件错放 WHERE，导致左表被意外过滤，实际变成 INNER JOIN。
典型错误：select * FROM user u LEFT JOIN order o ON u.id = o.user_id WHERE o.status = 'paid'。这里 WHERE 会把所有 o.status 为 NULL（即无订单或订单非 paid）的用户全干掉。
- 正确写法：把过滤条件挪到
ON子句：LEFT JOIN order o ON u.id = o.user_id AND o.status = 'paid' - 使用场景：用户维度宽表构建（补订单数、最近下单时间）、漏斗中「上一步有行为，下一步未必有」的关联（如注册 → 激活 → 付费）
- 兼容性注意：mysql 5.7+ 对
ON中的非关联条件支持稳定；postgresql 同样适用，但 sqlite 在复杂ON条件下可能退化为嵌套循环
FULL OUTER JOIN 在 MySQL 里根本不存在
MySQL 原生不支持 FULL OUTER JOIN，强行写会报错 Error 1064 (42000)。别信网上那些「用 LEFT + RIGHT + union 模拟」的通用方案——它们在有重复主键、NULL 值参与关联时极易出错，且性能灾难。
真实业务中需要「两表并集」的场景极少。多数所谓「要 FULL」的需求，本质是：要么该用 UNION ALL 合并两个独立查询结果（如「所有用户 + 所有客服」），要么其实是 LEFT JOIN 或 RIGHT JOIN 配合 IS NULL 判断（如查「有订单但无评价的订单」）。
- 替代方案优先级：先想是否能拆成两个
SELECT+UNION ALL；其次考虑LEFT JOIN ... WHERE right_table.id IS NULL；最后才评估模拟 FULL 的成本 - PostgreSQL/SQL Server 用户可直接用
FULL OUTER JOIN，但要注意：两表关联字段含NULL时，NULL = NULL不成立，需显式写ON (a.id = b.id) OR (a.id IS NULL AND b.id IS NULL) - 性能风险：FULL JOIN 在大数据量下基本等于笛卡尔积的子集，执行计划常走 Nested Loop，千万级表慎用
CROSS JOIN 是笛卡尔积，不是“随便连两个表”
CROSS JOIN 不带 ON 条件，就是暴力组合：左表 N 行 × 右表 M 行 = N×M 行。它唯一合理用途是生成固定维度组合，比如「所有商品 × 所有促销标签」预计算打标，或「日期序列 × 地区列表」补全缺失指标。
误用最常见于新手写关联时忘了加 ON，结果查出几亿行，数据库卡死。或者用它代替 INNER JOIN 再加 WHERE 过滤，自以为等价——其实优化器无法利用索引，执行效率远低于标准 JOIN。
- 安全用法：明确控制右表行数（如
(SELECT 'Q1' AS quarter UNION ALL SELECT 'Q2') q），且左表已用WHERE严格限定 - 禁止场景：任何涉及业务主表（
user、order、product）之间无条件连接 - 可读性提示：即使语法允许省略
JOIN关键字（FROM a, b），也务必显式写CROSS JOIN，避免和旧式逗号连接混淆
JOIN 类型选错，往往不是语法问题，而是对「业务语义中‘存在性’的定义」没理清。比如“查用户和其最近一笔订单”，重点在“最近一笔”——这本身是个子查询或窗口函数任务，硬套 LEFT JOIN 再加 MAX() 过滤，大概率得到错误结果。先想清楚“我要的数据在什么前提下才算有效”，再选 JOIN。