inner join只保留两表交集数据，不匹配行自动丢弃。其on条件决定连接逻辑，字段名错误、null值、类型不一致或路径缺失均导致结果为空，且无报错提示。
INNER JOIN 不是过滤工具，它是连接逻辑本身——它只保留两边都存在的行，不匹配的自动丢弃，不需要额外 WHERE。
ON 条件写错，结果就全空了
很多人把 INNER JOIN 当成“先拼再筛”，其实它在连接阶段就执行匹配判断。一旦 ON 条件写错（比如字段名打错、表别名没加、类型不一致），整条记录直接被排除，不是报错，而是静默消失。
- 常见错误：
ON users.id = orders.user_id写成ON users.id = orders.id，结果为空但无提示 - NULL 值天然不匹配：
users.id为NULL的行永远不会出现在INNER JOIN结果中 - 字段类型要一致：比如
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 中，二者有时效果一样，但语义和可维护性差很远。
- 想查“2025 年的订单及对应用户”：条件
o.created_at >= '2025-01-01'应该写在ON还是WHERE？——写在WHERE更合理，因为它是对已连接结果的限定 - 但如果写成
ON u.id = o.user_id AND o.status = 'paid'，就变成“只连已支付的订单”，逻辑更清晰，也避免后续再加WHERE搞混 - 关键区别：
ON影响连接行为，WHERE影响最终输出行数；混用容易在换成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 直接拒绝执行
真正难的不是写对语法，而是想清楚“哪些行本就不该出现”——INNER JOIN 的沉默丢弃特性，会让缺失数据问题藏得很深，尤其当关联字段缺乏外键约束或索引时，查不到结果往往不是 SQL 写错了，而是数据本身断链了。
