INNER JOIN 不是过滤工具，它是连接逻辑本身——它只保留两边都存在的行，不匹配的自动丢弃，不需要额外 WHERE。
很多人容易把 INNER JOIN 当成“先拼接再筛选”的工具，但实际上，它在连接阶段就已经完成了匹配判断。一旦 ON 条件写错，整条记录就会被默默排除，而且连个错误提示都不会给你，静默消失，非常坑人。
ON 条件写错，结果就全空了
最常见的问题就出在 ON 条件上。字段名打错、忘记加表别名、或者字段类型不一致，都会导致匹配失败。比如，`ON users.id = orders.user_id` 不小心写成了 `ON users.id = orders.id`，结果就会一片空白，但你找半天也找不到语法错误。
- NULL 值是另一个容易被忽略的点：`users.id` 为 NULL 的行，永远不会出现在 INNER JOIN 的结果里，因为 NULL 和任何值都不匹配。
- 字段类型必须一致。比如，拿 INT 类型的字段去直接比较 VARCHAR 类型的字段，MySQL 可能会隐式转换失败，而 PostgreSQL 则是直接报错。
多表连接时，顺序和路径必须存在
连接三个或更多表，可不是随心所欲地“任意两两配对”就行。你得按业务关系逐层链接。如果漏掉了中间的桥梁表，INNER JOIN 会因为找不到路径而返回空结果，而且这同样不是语法错误。
- 正确的路径应该是：`users` → `orders` → `order_items`，对应的连接条件是 `u.id = o.user_id` 和 `o.id = oi.order_id`。
- 错误写法比如：`users u INNER JOIN order_items oi ON u.id = oi.user_id`，因为 `order_items` 表里根本没有 `user_id` 这个字段。
- 表顺序不影响最终逻辑结果，但会影响执行计划。一个常用的优化技巧是：小表放前、大表放后，并且让索引字段位于 ON 条件的左侧，这样能显著提升查询效率。
别把 WHERE 当 ON 用
`WHERE` 是连接完成后的二次筛选，而 `ON` 是连接本身的匹配规则。在 INNER JOIN 场景下，有时候把条件写在 `ON` 和 `WHERE` 里效果一样，但从语义和可维护性上看，差别很大。
- 比如，要查“2025 年的订单及对应用户”，条件 `o.created_at >= '2025-01-01'` 应该放在哪？放在 `WHERE` 里更合理，因为它是对已连接结果的最终限定。
- 但如果写成 `ON u.id = o.user_id AND o.status = 'paid'`，意思就变成了“我只连接那些已经支付了的订单”，逻辑上更聚焦，也避免了后续加 `WHERE` 时搞混。
- 关键的区别在于：`ON` 影响连接行为本身，而 `WHERE` 影响最终输出的行数。如果现在用了 INNER JOIN 觉得无所谓，将来换成 LEFT JOIN 时，这种混用就可能引发意料之外的 Bug。
字段重复或歧义必须显式限定
INNER JOIN 之后，结果集会包含来自不同表的同名字段，比如两张表都有 `id`。如果不加表前缀或别名，SQL 要么直接报错，要么返回你压根不想要的字段。
- 正确的写法是：`SELECT u.id, u.name, o.id AS order_id, o.amount`，而不能简写成 `SELECT id, name, id, amount`。
- 别名不是为了让代码好看才加的，而是防止歧义的刚需：`FROM users u INNER JOIN orders o ON u.id = o.user_id`。
- 如果忘了限定字段，MySQL 可能默认取最后一个表的字段值，而 PostgreSQL 会直接拒绝执行，不给你犯错的机会。
其实，写对 SQL 语法并不难，难的是想清楚“哪些行本就不该出现”。INNER JOIN 这种“沉默式丢弃”的特性，会让数据缺失的问题藏得很深。尤其是当关联字段缺乏外键约束或索引时，查不到结果，往往不是 SQL 写错了，而是数据本身就已经断链了。
