INNER JOIN 是获取两表交集最直接的方式，仅返回联结字段值完全匹配的记录；必须用 ON 明确指定条件，要求字段类型一致、避免 NULL 和隐式转换，并推荐使用表别名防止歧义。
用 INNER JOIN 精准获取两表交集数据
想查 A 表和 B 表都存在的记录，INNER JOIN 是最直接、语义最清晰的选择。它只返回两个表中联结字段值完全匹配的行，天然对应“共有”这一逻辑。
常见错误是误用 LEFT JOIN 或 FULL OUTER JOIN 后再加 WHERE 过滤，不仅写法绕，还容易因 NULL 判断出错（比如 WHERE b.id IS NOT NULL 看似等价，但若联结字段本身允许 NULL，结果可能偏差）。
-
ON条件必须明确指定联结字段，且两边字段类型最好一致；隐式类型转换（如字符串 vs 数字）可能使索引失效或匹配失败 - 如果联结字段有重复值，
INNER JOIN会产生笛卡尔积效果——例如 A 表某 id 出现 3 次、B 表同 id 出现 2 次，结果会生成 6 行，这不是 bug，而是设计如此 - 建议在
ON子句里只放联结条件，在WHERE子句里放业务过滤条件（如时间范围、状态），避免意外排除本该匹配的行
当联结字段名不同时，别硬套同名列假设
实际场景中，A 表可能是 user_id，B 表却是 customer_no，名字不同但语义相同。这时候不能依赖“列名相同就自动匹配”的误解。
必须显式写出 ON a.user_id = b.customer_no。如果字段类型不一致（比如一个是 VARCHAR(10)，另一个是 INT），数据库可能报错或静默转换——MySQL 会尝试转成数字比较，PostgreSQL 则大概率直接报 operator does not exist 错误。
- 先用
SELECT分别查两表该字段的样本值和pg_typeof()（PostgreSQL）或DATA_TYPE（information_schema.COLUMNS）确认类型 - 必要时手动转换，如
ON a.user_id = CAST(b.customer_no AS INTEGER)，但尽量避免运行时转换，影响性能 - 别用
USING (col_name)语法，它要求两表字段名完全相同，适用场景有限
查“共有”但要避免重复行？考虑 DISTINCT 或 GROUP BY
如果只是想知道哪些 ID 同时存在于两表，不关心具体关联的明细行，那么 INNER JOIN 结果很可能包含重复 ID——尤其当一对多关系存在时。
这时不要在 JOIN 后加 DISTINCT 就完事。虽然能去重，但执行计划通常是先拼出全部匹配行再过滤，浪费资源。更优做法是把逻辑前置：
- 用
IN+ 子查询：SELECT id FROM a WHERE id IN (SELECT id FROM b)，适合小结果集；注意 MySQL 5.7+ 对IN子查询做了优化，但 PostgreSQL 中大子查询仍可能慢 - 用
EXISTS：SELECT id FROM a WHERE EXISTS (SELECT 1 FROM b WHERE b.id = a.id)，通常比IN更稳定，且能利用b.id上的索引 - 如果必须用
JOIN，且后续还要取其他字段，再配合DISTINCT ON (a.id)（PostgreSQL）或GROUP BY a.id控制粒度
LEFT JOIN + WHERE IS NOT NULL 不等于 INNER JOIN
有人习惯写 SELECT * FROM a LEFT JOIN b ON a.id = b.id WHERE b.id IS NOT NULL，以为等价于 INNER JOIN。表面上结果一样，但执行计划和语义有本质区别。
LEFT JOIN 先强制保留 A 表所有行，再过滤掉 B 表为 NULL 的部分；而 INNER JOIN 从一开始只考虑匹配对。优化器有时能重写，但并非总是——尤其当 B 表很大、且 b.id 上无索引时，LEFT JOIN 可能全表扫描 B，而 INNER JOIN 能更好利用联结条件做驱动选择。
- 检查执行计划：用
EXPLAIN看是否出现Hash Join或Nested Loop，以及哪张表被选为内表（inner table） - 如果 B 表远大于 A 表，确保
b.id有索引；否则INNER JOIN也可能变慢 - 别为了“看起来像左连接”而牺牲语义清晰性——用什么就写什么，让 SQL 自己说清意图
真正难的不是写对 JOIN，而是搞清“共有”到底指什么粒度：是主键值相同？还是业务上同一实体？后者往往需要多字段联结或额外清洗，光靠 SQL 无法解决。
