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 会穷举所有匹配对。
