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