INNER JOIN 不等价于集合交集，而是笛卡尔积后按ON条件过滤的行对组合，会产生重复行；真正等价的是IN或INTERSECT。

INNER JOIN 等价于集合交集吗？

严格来说，INNER JOIN 不是数学意义上的“集合交集”，而是基于连接条件的**笛卡尔积过滤结果**。它返回的是左表和右表中满足 ON 条件的**行对组合**，不是去重后的值集合。

常见误解是：把 SELECT id FROM t1 INNER JOIN t2 ON t1.id = t2.id 当作求两个 id 列的交集。但若某 id 在 t1 中出现 3 次、在 t2 中出现 2 次，结果会返回 3 × 2 = 6 行 —— 这明显不是交集（交集应只含该 id 一次）。

• 真正等价于集合交集的操作是：SELECT id FROM t1 WHERE id IN (SELECT id FROM t2) 或 SELECT id FROM t1 INTERSECT SELECT id FROM t2（MySQL 8.0.32+ 支持 INTERSECT）
• INNER JOIN 关注“关联关系”，不是“成员归属”；它天然携带重复和组合爆炸风险
• 如果两表 id 均为主键或唯一键，且你只 SELECT 其中一个 id，那结果看起来像交集——但这只是特例，不是本质

什么时候 INNER JOIN 会“意外膨胀”行数？

这是最常踩的坑：没意识到连接键不具备函数依赖性，导致结果行数远超预期。

SELECT u.name, o.order_id
FROM users u
INNER JOIN orders o ON u.id = o.user_id;

如果用户 John（id=1）下了 5 单，结果里就会有 5 行 John 的名字 —— u.name 被重复了 5 次。这不是 bug，是 JOIN 的正常行为。

• 检查连接字段是否在各自表中具有唯一性（如主键、带 UNIQUE 约束的列）
• 用 SELECT COUNT(*) 分别查两表连接键的重复分布：SELECT user_id, COUNT(*) FROM orders GROUP BY user_id ORDER BY COUNT(*) DESC LIMIT 5
• 若需去重聚合，应在 JOIN 后加 GROUP BY，或改用 EXISTS / IN

INNER JOIN 与 LEFT JOIN + WHERE IS NOT NULL 的区别

表面看，LEFT JOIN ... WHERE right_table.id IS NOT NULL 和 INNER JOIN 返回相同结果集，但执行逻辑和优化器行为可能不同。

• MySQL 优化器通常能将后者自动转换为 INNER JOIN，但前提是 WHERE 条件无函数包装、无隐式类型转换
• 若 right_table.id 允许为 NULL，且你在 WHERE 中写了 right_table.status = 'done'，那它就不再是等价替代 —— 因为 LEFT JOIN 会先保留所有左表行，再过滤，而 INNER JOIN 是直接跳过不匹配的左行
• 可读性上，明确想表达“必须有关联”时，优先写 INNER JOIN；避免用 LEFT JOIN + WHERE 曲线救国

性能与索引的关键点

INNER JOIN 性能几乎完全取决于连接字段是否有有效索引。没有索引时，MySQL 可能退化为嵌套循环全表扫描（type: ALL）。

• 连接条件中的字段，**两边都建议建索引**。例如 ON t1.a = t2.b，则 t1(a) 和 t2(b) 都应有索引
• 复合索引要注意最左前缀：若写 ON t1.x = t2.y AND t1.z > 10，t1(x,z) 比单列 t1(x) 更高效
• 用 EXPLAIN 看 key 和 rows：如果 key 为 NULL 或 rows 接近全表，基本可以确定缺索引

交集类需求如果只是判断存在性，EXISTS 往往比 INNER JOIN 更轻量，因为它找到第一个匹配就停止；而 JOIN 会穷举所有匹配对。