多表JOIN必须显式使用表别名限定所有字段，禁止SELECT *；ON、GROUP BY、ORDER BY等子句须与SELECT保持别名一致；CTE和子查询中别名作用域独立，需逐层规范。
SELECT 中字段名重复导致查询报错或结果错乱
多表 JOIN 时，若两张表都有 id、name 等同名字段，不加别名直接写 SELECT * 或裸字段名，数据库要么报错（如 PostgreSQL），要么返回不可预测的字段顺序（MySQL 5.7+ 默认拒绝裸 * 在有歧义时使用）。更隐蔽的问题是：应用层取值时用 row["name"] 拿到的可能是 A 表还是 B 表的值，完全依赖执行计划。
解决方式不是靠“避免重名”，而是强制显式声明归属：
- 对每个可能冲突的字段，必须用
表别名.字段名形式写出，例如a.name、b.name -
SELECT *在多表场景下应视为禁用操作；哪怕只用于调试，也要先确认执行计划中字段顺序 - 表别名建议用有意义的缩写（如
user u、order o），而非t1、t2—— 后者在嵌套 3 层后根本无法维护 - MySQL 允许
SELECT u.id, o.id这种写法，但 PostgreSQL 会直接报错column "id" is ambiguous，所以跨数据库项目务必统一按严格模式写
ON 条件里漏写表别名引发逻辑错误
ON 子句不是可有可无的装饰，它是关联逻辑的唯一定义位置。如果这里没加别名，SQL 可能意外走成笛卡尔积，或者因字段解析失败而退化为隐式内连接（尤其在旧版 MySQL 中）。
典型错误写法：ON user_id = id —— 数据库不知道 id 是哪张表的，可能匹配到当前作用域任意表，也可能报错。
正确做法是：所有 ON 中的字段都带前缀，且左右表明确对应：
- 左表字段写
u.user_id，右表字段写o.user_id，不要省略任何一个 - 如果关联字段名不同（如
user.uid↔order.owner_id），必须两边都写全，不能只写一边 - 外连接（
LEFT JOIN）中，ON的条件只影响右表匹配行为；把本该放WHERE的过滤条件误塞进ON，会导致右表 NULL 行被意外保留或剔除
GROUP BY / ORDER BY 中未同步更新别名引用
很多人在 SELECT 加了别名后，忘了 GROUP BY 和 ORDER BY 也得保持一致。比如写了 SELECT u.name AS username，却在 ORDER BY name —— 这里的 name 是未定义的，PostgreSQL 直接拒绝，MySQL 可能回退到找原始表字段，结果排序错乱。
关键原则：只要 SELECT 中用了别名，GROUP BY 和 ORDER BY 必须用该别名；如果没用别名，则必须用带前缀的原始字段名。
- 推荐统一风格：全部用别名（
SELECT u.name AS user_name→ORDER BY user_name） - 禁止混用：
SELECT u.name, COUNT(*)后写GROUP BY u.name是 OK 的，但若同时有o.status就必须一起带上，否则 MySQL 5.7+ 会报错Expression #1 of SELECT list is not in GROUP BY clause - 窗口函数中尤其容易出错，如
ROW_NUMBER() OVER (ORDER BY u.created_at)，这里的u.created_at必须存在且可访问，不能依赖 SELECT 别名
子查询和 CTE 中别名作用域容易被忽略
子查询的表别名只在该子查询内部有效，外部不能直接引用其字段，除非在外部 SELECT 中再次加前缀。CTE（WITH）同理：CTE 定义中的字段名就是它的“公开接口”，外部引用时不能再加原表前缀。
例如：
WITH user_orders AS ( SELECT u.id, u.name, o.amount FROM user u JOIN order o ON u.id = o.user_id ) SELECT id, name FROM user_orders;
这里不能写 SELECT u.id，因为 u 在 CTE 外已不可见；也不能写 SELECT user_orders.id，CTE 名不是表别名，只是逻辑名。
- CTE 内部仍需规范别名（
u.id AS user_id），否则外部SELECT里字段名仍是id，又回到开头的冲突问题 - 嵌套子查询时，最内层的别名对外层不可见，每层都得重新声明，不能图省事复用上层别名
- 某些 ORM（如 Django ORM）生成 SQL 时会自动加别名，但手写原生 SQL 时，这一步必须自己控制，没有“默认安全”这回事
ON 或 GROUP BY），整条语句的行为就可能偏离预期，而这种错误往往在线上跑了一周才暴露。 
