必须为每个可能冲突的字段显式加表前缀并重命名，只靠AS不写前缀等于没做，因为多表同名列在结果集层面会被覆盖或报错，WHERE/ON等子句无法识别SELECT中定义的别名，且跨数据库兼容性差，唯有全程统一使用带前缀的原始名或通过子查询/视图隔离作用域才能彻底规避歧义。

必须为每个可能冲突的字段显式加表前缀并重命名，只靠 AS 不写前缀等于没做。

为什么 SELECT u.id AS id, o.id AS id 依然报错或取值错乱

多数数据库（如 PostgreSQL、SQL Server）和客户端（psycopg2、JDBC）在结果集层面只认列名字符串。两个 AS id 会被视为同名列，后一个覆盖前一个——最终你拿到的 row["id"] 永远是右表的值，且无法预测顺序。

• MySQL 5.7+ 默认拒绝这种写法，直接报 Column 'id' in field list is ambiguous
• 即使 MySQL 8.0 允许执行，fetchall() 返回的元组里也只剩一个 id 字段
• ORM（如 Django 的 values()）会因字段名重复而抛出 FieldError

WHERE 和 ORDER BY 中不能用 SELECT 里的别名

SQL 执行顺序是 FROM → WHERE → GROUP BY → SELECT → ORDER BY，WHERE 阶段根本看不到 SELECT 里定义的 AS 别名。

• 错误写法：SELECT u.id AS user_id FROM users u WHERE user_id = 123 → 报 Unknown column 'user_id' in 'where clause'
• 正确写法：WHERE u.id = 123 或 WHERE users.id = 123
• ORDER BY 虽然标准 SQL 允许用 SELECT 别名，但跨数据库兼容性差；更稳妥的是统一用 u.created_at 或序号（如 ORDER BY 2），但后者易随字段增减失效

ON 条件里漏表前缀比 SELECT 更危险

ON 是 JOIN 的逻辑核心，这里字段解析失败不会“默默跳过”，而是直接中断或退化成笛卡尔积。

• 错误写法：ON user_id = id → 若 users 和 orders 都有 id 和 user_id，数据库无法判断左右归属
• PostgreSQL 直接报 column reference "user_id" is ambiguous
• MySQL 可能隐式匹配，但一旦字段类型不一致（如 BIGINT vs INT），索引失效，查询变慢数倍
• 正确写法：ON u.id = o.user_id，两边都带前缀，无歧义

嵌套查询或视图是唯一能“隔离”别名作用域的方式

子查询或视图内部完成重命名后，外层看到的只有已处理过的字段名，彻底规避作用域混乱。

• 子查询示例：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, ...
• 注意：视图字段名以定义时为准，后续基表改名不影响视图输出结构

最常被忽略的一点：别名不是“写一次就完事”的装饰，它必须贯穿整个查询的所有子句——SELECT、ON、WHERE、GROUP BY、ORDER BY 全部要同步更新，漏掉任意一处都可能让前面的重命名白费功夫。