什么时候必须用 JOIN 而不是 WHERE 多表拼接
用
WHERE在单个
SELECT里写多个表名（如
SELECT * FROM a, b WHERE a.id = b.a_id）看似能查，但这是隐式内连接，可读性差、易漏条件、无法表达外连接语义。真正需要联合查询时——比如要保留主表所有记录（即使关联表没匹配项），就必须用显式
JOIN语法。
常见踩坑：把
LEFT JOIN写成逗号分隔 +
WHERE，结果因
WHERE过滤掉了 NULL 行，实际变成内连接。 左表有 100 条，右表只有 20 条匹配 → 用
LEFT JOIN得到 100 行；用
WHERE关联再加
AND b.status = 'active'，可能只剩 15 行（NULL 行被干掉）
ON是连接条件，只决定“怎么连”；
WHERE是过滤条件，作用于连接后的临时结果集 多表连接时，
ON可引用前面已出现的表，但不能引用后面还没
JOIN的表（MySQL 会报
Unknown column）
INNER JOIN / LEFT JOIN / RIGHT JOIN 的行为差异
核心区别不在“谁在左谁在右”，而在“保留哪边的未匹配行”。
INNER JOIN只返回两边都匹配的行；
LEFT JOIN以左表为基准，右表无匹配则补 NULL；
RIGHT JOIN同理，但极少用——完全可用调换表序的
LEFT JOIN替代。
示例场景：查用户订单数，包括从未下单的用户：
SELECT u.id, u.name, COUNT(o.id) AS order_cnt FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id, u.name
如果这里写成
INNER JOIN，那些
order_cnt = 0的用户就直接消失了。
LEFT JOIN后跟的
WHERE条件若涉及右表字段（如
WHERE o.status = 'paid'），会把左表未匹配行过滤掉 → 想保留就得写成
ON ... AND o.status = 'paid'多个
LEFT JOIN串连时，第二层
ON可同时引用第一张左表和中间表，但不能跳过中间表直接引用更早的表（除非用子查询）
STRAIGHT_JOIN可强制 MySQL 按 FROM 后顺序读表，对复杂多表连接有时能避免错误的驱动表选择
UNION 和 JOIN 的根本区别别搞混
UNION是纵向合并结果集，要求列数、类型兼容；
JOIN是横向拼接记录。想把“用户列表”和“管理员列表”合起来显示？用
UNION；想查“用户 + 他的收货地址 + 最近一笔订单”？必须用
JOIN。
常见误用：用
UNION去拼不同结构的表，导致字段错位或隐式类型转换（比如把
user.name当作
order.amount显示）。
UNION默认去重，
UNION ALL不去重、性能更好，除非真需要 dedup，否则优先选
ALL
UNION各子查询不能有各自
ORDER BY，只能最外层加
ORDER BY；若需每个子集内部排序，得套一层子查询 混合
JOIN和
UNION时，注意括号优先级：
(a JOIN b) UNION (c JOIN d)和
a JOIN (b UNION c) JOIN d完全是两回事
性能关键：连接字段一定要有索引
没索引的
JOIN字段会让 MySQL 走嵌套循环（Nested Loop），数据量稍大就慢得明显。比如
orders.user_id没索引，10 万用户 × 平均 5 单，可能触发 50 万次全表扫描。
检查方式：
EXPLAIN SELECT ...看
type是否为
ref或
eq_ref，
key列是否显示用了哪个索引。 复合索引要注意最左前缀：如果
ON a.x = b.x AND a.y = b.y，那么
b(x,y)索引有效，
b(y,x)无效
STRAIGHT_JOIN配合
FORCE INDEX有时比优化器自动选的执行计划更稳，尤其当统计信息不准时 大表
JOIN小表，小表最好做驱动表（即
FROM后第一个表），避免大表被反复扫描
多表连接容易在
ON条件、索引覆盖、NULL 处理上出问题，调试时先用
EXPLAIN看执行计划，再逐层加
LIMIT 10观察中间结果，比硬猜快得多。
