所有多表join查询中，同名字段必须显式加表别名前缀，select *禁用；因字段歧义会导致报错、覆盖、数据丢失，且as不可省略，on/where/order by等各子句须全程统一使用带前缀的字段名。
直接结论：所有多表 JOIN 查询中，只要两张表存在同名字段（如 id、name、created_at），就必须对每个可能冲突的字段显式加上表别名前缀，SELECT * 在这种场景下应视为禁用操作。
为什么 SELECT u.id, o.id 会报错或取错值
MySQL 5.7+ 默认拒绝执行含歧义字段的查询；即使在 MySQL 8.0 中允许，fetchall() 或 ORM 返回的结果集里也只剩一个 id 字段——后声明的覆盖先声明的，你永远拿不到左表的 id。更隐蔽的是，某些客户端（如旧版 JDBC 驱动）会把 u.id 和 o.id 都映射成键 "id"，导致数据丢失。
- 错误写法：
SELECT u.id, o.id FROM users u JOIN orders o ON u.id = o.user_id→ 报Column 'id' in field list is ambiguous - 正确写法：
SELECT u.id AS user_id, o.id AS order_id，且必须保证每个字段都重命名 - AS 不可省略在语义关键处：虽然
u.id user_id合法，但团队协作中显式写AS能避免误读
ON 子句里漏表前缀比 SELECT 更危险
ON 是关联逻辑的唯一定义位置，这里字段解析失败不会“跳过”，而是直接中断或退化为笛卡尔积。尤其当字段名在多张表中都存在时，数据库根本无法判断归属。
- 错误写法：
ON user_id = id→user_id和id都在users和orders中存在，PostgreSQL 直接报错，MySQL 可能隐式匹配但索引失效 - 正确写法：
ON u.id = o.user_id，左右两边都带前缀，无任何歧义 - 即使某字段只在一张表中有（如
orders.status），也建议写成o.status—— 后续加表时不会突然崩
WHERE 和 ORDER BY 不能用 SELECT 里的 AS 别名
SQL 执行顺序是 FROM → WHERE → GROUP BY → SELECT → ORDER BY，WHERE 阶段根本看不到 SELECT 里定义的别名。依赖别名写条件，必然报 Unknown column 'xxx' in 'where clause'。
- 错误写法：
SELECT u.id AS user_id FROM users u WHERE user_id = 123 - 正确写法：
WHERE u.id = 123或WHERE users.id = 123 -
ORDER BY虽然标准 SQL 允许用别名，但跨数据库兼容性差；稳妥做法是统一用u.created_at或序号（如ORDER BY 2），但后者随字段增减极易失效
嵌套子查询是唯一能彻底隔离别名作用域的方式
当连接逻辑复杂、或需复用一组已重命名字段时，子查询或视图是最干净的解法。外层看到的只有子查询输出的列名，原始表结构完全不可见，天然规避所有歧义。
- 子查询示例：
SELECT * FROM (SELECT u.id AS user_id, o.id AS order_id FROM users u JOIN orders o ON u.id = o.user_id) t WHERE t.user_id > 100 - 视图创建强制要求
AS：CREATE VIEW user_orders AS SELECT u.id AS user_id, o.amount AS order_amount FROM users u JOIN orders o ON u.id = o.user_id - 注意：视图字段名以定义时为准，后续基表改名、加字段不影响视图查询
最容易被忽略的一点：别名不是“写一次就完事”的装饰。它必须贯穿整个查询——SELECT、ON、WHERE、GROUP BY、ORDER BY 全部同步使用，缺一不可。任何一处漏掉，都可能让整条 SQL 在换环境、加表、升级数据库版本时突然失效。
