inner join查不到数据主因是关联字段无交集，需先用select distinct确认；on须紧随join后；字段冲突要加表别名；误用inner替代left会丢失左表无匹配记录；on中混用and易致逻辑错误；多表连接须显式写on且用别名。
INNER JOIN 语法写错会导致查不到数据
很多人写 INNER JOIN 时直接照搬“SELECT * FROM a JOIN b ON a.id = b.a_id”，结果返回空——其实是因为没确认两张表里真的存在匹配的关联值。比如 users 表里 id = 5，但 orders 表中所有 user_id 都是 1~4，那这条连接就完全不生效。
实操建议：
- 先单独查一遍两边的关联字段，用
SELECT DISTINCT user_id FROM orders和SELECT DISTINCT id FROM users确认交集存在 -
ON子句必须写在JOIN后面，不能写成WHERE（虽然结果可能一样，但语义和执行计划不同） - 字段名冲突时必须加表别名，例如
SELECT u.name, o.created_at FROM users u INNER JOIN orders o ON u.id = o.user_id
LEFT JOIN 误写成 INNER JOIN 会丢数据
业务上常需要“查出所有用户及其订单数”，这时如果用 INNER JOIN，那些没下过单的用户就彻底消失了。这不是 bug，是 INNER JOIN 的定义决定的：只保留左右表都存在的匹配行。
判断依据很简单：
- 要“以左表为主、右表可为空” → 用
LEFT JOIN - 要“两表必须都有对应记录” → 才用
INNER JOIN - 连表顺序不影响
INNER JOIN结果，但影响LEFT/RIGHT JOIN，别混淆
ON 条件里混用 AND 和 WHERE 会改变结果
把过滤条件错误地放在 ON 里，是跨表查询最隐蔽的坑。例如：SELECT * FROM users u INNER JOIN orders o ON u.id = o.user_id AND o.status = 'paid'，这会先筛出已支付的订单再连接；而写成 ... ON u.id = o.user_id WHERE o.status = 'paid'，逻辑一样，但若换成 LEFT JOIN，效果就完全不同。
对 INNER JOIN 来说，ON 和 WHERE 在最终结果上通常等价，但：
- 数据库优化器可能生成不同执行计划，影响性能
- 换到
LEFT JOIN时行为突变，容易埋雷 - 团队协作中语义不清，建议统一把非关联条件挪到
WHERE
多表 JOIN 时别漏掉括号或别名
三个表以上连接时，不加别名会让 SQL 很难读，也容易写错字段归属。比如 SELECT * FROM users JOIN orders JOIN products 没指定连接条件，多数数据库直接报错 ERROR: missing JOIN condition。
安全写法：
- 每张表都起短别名：
u,o,p - 每个
JOIN后立刻跟ON，不要堆到最后 - 避免隐式连接（逗号分隔表名），它和
INNER JOIN语义不同且易出错
复杂点往往不在语法，而在你默认“两张表肯定能对上”——实际生产环境里外键缺失、空值、类型不一致（比如 user_id 是字符串而 id 是整型）才是最常见的失败原因。
