多表查询必须显式指定字段并加表别名，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 语法里，但每一步都在决定你查出来的到底是数据，还是幻觉。
