多表查询必须显式指定字段并加表别名，JOIN顺序与类型需匹配业务逻辑，ON与WHERE用途不可混淆，同时警惕NULL、类型转换和隐式截断等数据陷阱。

SELECT 多表字段时别直接写 *，先想清楚要哪几列

很多人一写多表查询就习惯性用 SELECT *，结果查出几十个重复字段（比如两个表都有 id、created_at），程序解析时直接报错或取错值。真正该做的，是显式列出每个字段，并带上表别名前缀。

• 用 SELECT user.id, order.amount, order.status 替代 SELECT *
• 一旦涉及 JOIN，所有字段必须明确归属，比如 user.name 而不是 name（否则 MySQL 8.0+ 会报 Column 'name' in field list is ambiguous）
• 如果字段名相同但语义不同（如 user.id 和 order.user_id），不加别名会导致后续逻辑混淆

JOIN 顺序和类型决定你能拿到什么数据，不是语法对就行

写 LEFT JOIN 却把主表放在右边，或者用 INNER JOIN 但实际需要保留左表全部记录——这类错误不会报语法错，但结果集永远少数据。

• 主表（驱动表）放 FROM 后面；关联表放 JOIN 后面：正确是 FROM users LEFT JOIN orders ON users.id = orders.user_id
• INNER JOIN 只返回两表都匹配的行；LEFT JOIN 保证左表全量，右表缺失字段为 NULL；选错类型，分页数、统计总数都会偏差
• 多个 JOIN 时，优先把过滤条件强（如带索引、数据量小）的表往前放，能减少中间结果集大小

WHERE 和 ON 的位置差一个字段，结果可能差十倍

ON 是连接条件，WHERE 是最终过滤条件。把本该写在 WHERE 的条件错塞进 ON（尤其在 LEFT JOIN 中），会让右表“假性消失”。

• 错误写法：LEFT JOIN orders ON users.id = orders.user_id AND orders.status = 'paid' → 用户没订单或订单非 paid，orders.* 全为 NULL，但用户还在
• 正确写法：LEFT JOIN orders ON users.id = orders.user_id WHERE orders.status = 'paid' OR orders.status IS NULL 或更清晰地拆开逻辑
• 性能上，ON 中的条件能参与连接算法优化；WHERE 中的条件在连接后才执行，大数据量时延迟明显

别忽略 NULL 和类型隐式转换带来的坑

多表 SELECT 最容易被忽视的是字段值的实际状态：空值、字符串拼接截断、数字精度丢失、时区差异。这些不会报错，但业务逻辑会悄悄出错。

• COALESCE(order.amount, 0) 比直接写 order.amount 更安全，避免空值导致求和/平均值异常
• 跨库或跨表连接时，确认时间字段是否同为 DATETIME 或 TIMESTAMP，MySQL 中两者在时区处理上行为不同
• 字符串字段长度超限（如 VARCHAR(10) 存了 15 字符），部分数据库会静默截断，SELECT 出来就是错的，得靠 CHAR_LENGTH() 校验

字段要不要加索引、JOIN 条件有没有走索引、NULL 值怎么参与计算——这些不在 SELECT 语法里，但每一步都在决定你查出来的到底是数据，还是幻觉。