必须用 join 而不是 where 多表拼接，因为 where 方式仅为隐式内连接，无法表达外连接语义，且 where 过滤会剔除 left join 产生的 NULL 行，导致逻辑错误。
什么时候必须用 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 观察中间结果，比硬猜快得多。