INNER JOIN 返回两表中ON条件为真且字段值均存在的记录，即严格交集；必须显式指定等值关联条件，字段类型需一致，NULL值参与比较会导致行被过滤。
INNER JOIN 就是取两个表的主键交集
只要两张表有相同主键字段（比如 id），INNER JOIN 会自动只保留两边都存在的记录——它不是“模拟交集”，它本身就是关系代数里的自然交集操作。不需要额外去重、不用子查询，只要 ON 条件写对，结果就是严格意义上的共有记录。
ON 条件必须用等值比较，且字段类型要一致
常见错误是写成 ON t1.id = t2.name 或忽略类型隐式转换风险。比如 user.id 是 INT，而 order.user_id 是 VARCHAR，某些数据库（如 MySQL）可能强行转换但丢失精度，导致本该匹配的记录被漏掉。
- 务必确认两边字段语义相同、类型一致，必要时显式
CAST(t2.user_id AS INT) - 避免在
ON中使用函数，例如ON LOWER(t1.email) = LOWER(t2.email)，会阻止索引使用 - 如果主键是复合的（如
(org_id, item_code)），ON必须完整写出两个条件，缺一不可
别把 INNER JOIN 和 EXISTS 搞混：性能和语义都不同
INNER JOIN 返回的是拼接后的宽表；EXISTS 只判断存在性，不展开字段。如果你只需要知道“哪些用户下过单”，用 EXISTS 更轻量；但如果你要查“用户姓名 + 最近下单时间”，就必须用 INNER JOIN。
-
INNER JOIN结果行数 ≤ 左表行数，但可能 > 左表（如果右表对左表某行有多条匹配） - 若右表存在重复主键（违反约束），
INNER JOIN会放大左表数据——这是业务逻辑问题，不是 SQL 错误 - 在 PostgreSQL 或 SQL Server 中，带
LIMIT的INNER JOIN可能因优化器选择 Nested Loop 而变慢，此时加USING (id)或确保关联字段有索引更稳妥
主键没索引？JOIN 会慢得超出预期
即使语义完全正确，没有索引的 ON 字段会让 INNER JOIN 退化为嵌套循环全表扫描。尤其当一张表百万级、另一张十万级时，执行时间可能从毫秒跳到分钟。
- 检查执行计划：MySQL 看
EXPLAIN输出中type是否为ref或eq_ref，而不是ALL - 复合主键场景下，索引顺序必须和
ON中字段顺序一致，否则无法命中 - 临时表或 CTE 产生的中间结果默认无索引，需要显式
CREATE INDEX（部分数据库支持）或改用物化视图
INNER JOIN 后必须跟 WHERE 筛选，而不是把条件塞进 ON——后者可能意外改变连接语义，尤其涉及外连接时。 
