JOIN 语法写错，查不到数据？先看连接条件是否匹配
MySQL 中
JOIN不是“自动连上就行”，核心在于
ON后的条件是否真能匹配出记录。常见错误是用了
LEFT JOIN却在
WHERE里对右表字段加非空限制，结果变成隐式
INNER JOIN。
比如：
SELECT u.name, o.order_id FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid';
这条语句会过滤掉所有
o.status为 NULL 的行（即没订单的用户），实际等价于
INNER JOIN。要保留左表全部用户，得把条件挪到
ON子句里：
SELECT u.name, o.order_id FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid';
ON是连接时判断依据，决定哪些右表行参与拼接
WHERE是连接完成后再过滤整行，可能把左表“拖下水” 多表连接时，每个
JOIN都要有自己的
ON，不能只写一个
INNER JOIN 和 LEFT JOIN 到底该选哪个？看业务语义
不是性能问题，是逻辑问题。
INNER JOIN表示“只取双方都有对应关系的数据”，
LEFT JOIN表示“以左表为主，右表可有可无”。选错会导致漏数据或误算。
典型场景：
统计每个用户的订单数 → 用LEFT JOIN+
COUNT(o.id)，否则没订单的用户直接消失 查已支付订单的用户邮箱 → 用
INNER JOIN，因为不需要“没订单”或“订单没支付”的记录 连三张表（users → orders → order_items）→ 前两个用
LEFT JOIN，第三个却用
INNER JOIN，可能让整个链路变严格，需逐层确认语义
连接字段类型不一致，索引失效还慢得离谱
哪怕
users.id和
orders.user_id看起来都是数字，如果一个是
INT、一个是
VARCHAR，MySQL 就无法使用索引，还会触发隐式类型转换，全表扫描。
检查方法：
执行SHOW CREATE TABLE users;和
SHOW CREATE TABLE orders;，对比字段类型和字符集 用
EXPLAIN看
type是否为
ALL或
index，
key是否显示用了索引 连接字段必须同类型、同字符集（尤其
VARCHAR字段带
utf8mb4和
utf8混用时）
修复建议：统一改为
INT UNSIGNED或都用
BIGINT，避免字符串存 ID。
ORDER BY + LIMIT 放在哪张表上？别让 JOIN 白算
如果只想取“每个用户最新一条订单”，写成：
SELECT u.name, o.order_id, o.created_at FROM users u LEFT JOIN orders o ON u.id = o.user_id ORDER BY o.created_at DESC LIMIT 10;
这会先做笛卡尔积再排序，效率极低。正确做法是先在
orders表里按用户分组取最新，再连用户表：
SELECT u.name, latest.order_id, latest.created_at
FROM users u
LEFT JOIN (
SELECT user_id, order_id, created_at,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) rn
FROM orders
) latest ON u.id = latest.user_id AND latest.rn = 1;
大表连接前，优先用子查询或 CTE 过滤/聚合右表
ORDER BY和
LIMIT尽量靠近数据源，别放在最终结果上 MySQL 8.0+ 支持窗口函数，比老式
GROUP BY + MAX()更准（避免拿错其他字段值）
多表 JOIN 的复杂度不在语法，而在你是否清楚每一行从哪来、为什么存在、有没有被意外过滤——这些地方一松动，结果就不可信。
