JOIN语法错误会导致结果为空或笛卡尔积；ON条件漏写、字段错用、WHERE误代ON是主因；LEFT JOIN中右表非空条件须放ON；GROUP BY需与SELECT非聚合字段严格一致；UNION ALL比UNION快2–5倍；关联字段类型不一致将致索引失效。
JOIN 语法写错会导致结果为空或笛卡尔积
MySQL 多表联合查询最常见问题不是“不会写”，而是 ON 条件漏写、写错字段，或者误用 WHERE 替代 ON。比如左连接时把关联条件放到 WHERE 里，会把本该保留的左表空匹配行过滤掉，实际变成内连接效果。
实操建议：
- 所有
JOIN后必须跟ON，哪怕只是临时测试也别省略 -
LEFT JOIN的过滤条件：关联字段放ON，左表自身条件放WHERE，右表非空限制（如t2.status = 'active'）要放ON，否则会失效 - 用
EXPLAIN看执行计划，重点检查type是否为ALL（全表扫描），以及key是否用了索引
多对一/一对多场景下 GROUP BY 容易漏加字段
比如查「每个用户最新一条订单」，用 JOIN + MAX(order_time) 再关联原表时，若没在 GROUP BY 中包含用户所有需要展示的字段（如 user_name, email），MySQL 5.7+ 会直接报错：Expression #3 of SELECT list is not in GROUP BY clause。
实操建议：
- 开启
sql_mode=ONLY_FULL_GROUP_BY（默认已开），强迫你写规范 - 不要依赖 MySQL 的“隐式分组”，宁可用子查询或窗口函数（MySQL 8.0+ 支持
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time DESC)） - 确认
GROUP BY字段和SELECT中非聚合字段完全一致，包括别名不能混用
UNION 和 UNION ALL 性能差异比想象中大
当需要合并多个查询结果（如「今日订单 + 昨日订单」），很多人默认写 UNION，但它会自动去重 + 排序，即使你根本不需要。如果两个结果集天然无交集（比如按日期分割），用 UNION ALL 能省掉排序和去重开销，实测快 2–5 倍。
实操建议：
- 只要确定结果不重复，一律优先用
UNION ALL -
UNION要求各子查询列数、类型兼容，遇到INT和VARCHAR混用会隐式转换，可能触发全表扫描 - 合并前先检查字段顺序是否一致，
SELECT a,b FROM t1 UNION SELECT b,a FROM t2是错的，字段位置必须对齐
关联字段类型不一致导致索引失效
这是线上最隐蔽的性能杀手：比如用户表 user_id 是 BIGINT，订单表外键却是 VARCHAR(20)，即使值看起来一样，MySQL 也无法走索引，JOIN 变成全表扫描。
实操建议：
- 用
SHOW CREATE TABLE对比两边字段定义，特别注意CHAR/VARCHAR长度、有无UNSIGNED、字符集是否一致（如utf8mb4vsutf8） - 修改前先用
ALTER TABLE ... MODIFY COLUMN统一类型，避免用函数包装字段（如CAST(t2.user_id AS SIGNED)）来“绕过” - 上线前在测试库用
EXPLAIN FORMAT=JSON查看used_columns和key_length，确认是否命中索引
DESCRIBE 和 EXPLAIN 说真话。 
