MySQL的JOIN底层基于笛卡尔积加选择运算，但非标准集合操作：不自动去重、不保证顺序、允许重复行且NULL比较特殊；必须显式写ON条件，否则报错；LEFT JOIN中ON与WHERE语义不同，误用会导致退化为INNER JOIN；性能取决于驱动表选择和ON字段索引。
JOIN 的底层确实是集合运算，但 MySQL 不按标准集合论执行
MySQL 的 JOIN 在语义上借鉴了关系代数中的笛卡尔积 + 选择（σ），但它不是纯集合操作：没有自动去重、不保证顺序、允许重复行存在，且 NULL 参与比较时行为特殊（NULL = NULL 为 UNKNOWN，不匹配）。真正接近集合的是 UNION（默认去重）和子查询配合 DISTINCT。
INNER JOIN 和笛卡尔积的关系必须手动加 ON 才生效
写 SELECT * FROM t1 JOIN t2 而不带 ON 或 USING，MySQL 会报错 ERROR 1064（语法错误），这和某些旧版 SQL 或教学模型不同。它强制要求显式关联条件，避免意外的全量叉乘。实际执行分两步：
- 先生成逻辑上的笛卡尔积（所有
t1行 × 所有t2行） - 再用
ON条件做过滤，等价于WHERE，但语义更清晰、外连接时不可替换
SELECT a.id, b.name FROM users a INNER JOIN orders b ON a.id = b.user_id;
LEFT JOIN 的“左表保留”特性容易被 WHERE 误杀
这是最常踩的坑：把本该写在 ON 的过滤条件错放到 WHERE，会导致 LEFT JOIN 退化成 INNER JOIN。因为 WHERE 是在连接结果上二次筛选，而 ON 是连接过程中的匹配约束。
-
ON b.status = 'paid'：只让orders中已支付的订单参与关联，users仍全部保留（没匹配到则b.*为NULL） -
WHERE b.status = 'paid'：先做LEFT JOIN，再筛掉所有b.status不是'paid'的行 —— 包括b.status IS NULL的行，结果只剩有支付订单的用户
性能关键点：驱动表选择和索引是否命中 ON 字段
MySQL 用嵌套循环（Nested Loop）实现 JOIN，先选一个表作为驱动表（通常小结果集的表），对它的每行去另一表查匹配。所以：
-
ON字段必须有索引，否则被驱动表要全表扫描（type: ALL） - 如果
EXPLAIN显示rows值巨大，优先检查ON列是否走了索引，而不是换JOIN类型 -
STRAIGHT_JOIN可强制指定驱动表，但仅当优化器选错且你确认更优时才用
复杂关联中，JOIN 本质不是集合操作的“优雅抽象”，而是带约束的行级遍历 —— 理解这点，才能避开幻觉优化。
