列名冲突会导致SQL引擎无法确定字段来源，引发静默错配或报错；子查询必须加语义化别名；WHERE中不可用SELECT定义的别名；多层嵌套需独立命名并显式重命名输出列。
列名冲突让SQL引擎“认错人”
当子查询和外层表有同名列（比如都叫 id 或 name），而你又没加表前缀或别名，SQL 引擎在解析时就无法确定你指的到底是哪一张表的字段。MySQL 可能取最后一个出现的 id 值，PostgreSQL 直接报 column reference "id" is ambiguous，SQLite 则按内部顺序“随机”选一个——这不是报错，而是静默错配。
最危险的是“看似能跑”，比如：SELECT id, name FROM users JOIN orders ON users.id = orders.user_id
如果两表都有 id，SELECT * 在 MySQL 里不会报错，但返回的 id 到底是用户的还是订单的？没人能保证，换版本、加索引、甚至只是服务器负载变化，结果都可能变。
FROM 子查询不加别名直接崩
所有主流数据库（MySQL、PostgreSQL、SQL Server、Oracle）都强制要求：出现在 FROM 中的子查询必须带表别名。不加会立刻报错，不是警告。
- MySQL 报
Every derived table must have its own alias - SQL Server 报
Must specify table alias - PostgreSQL 报
subquery in FROM must have an alias
别名不能只是 t1、sub 这种占位符，得有语义，比如 recent_orders 或 active_users。否则后续维护时，谁还记得 t1.id 是用户 ID 还是订单 ID？
WHERE 里用 SELECT 别名会报 Unknown column
SQL 执行顺序是 FROM → WHERE → GROUP BY → SELECT → ORDER BY，所以 WHERE 根本看不到 SELECT 里定义的别名（比如 u.id AS user_id）。你在 WHERE 写 user_id = 123，数据库会直接报 Unknown column 'user_id' in 'where clause'。
正确做法只有两个：
- 在
WHERE里用原始字段+表别名，如u.id = 123 - 把逻辑提前到子查询内部，比如子查询里写
SELECT u.id AS user_id FROM users u WHERE u.status = 'active'，外层再用t.user_id（t是子查询别名）
多层嵌套时别名复用等于自埋地雷
三层子查询里，如果每层都用 u 作用户表别名，引擎可能把不同层级的 u 当成同一个作用域，导致字段绑定错乱。更隐蔽的问题是 UNION 场景：(SELECT id, name FROM users) u UNION ALL(SELECT id, name FROM admins) u
外表 SELECT * 时，两个 id 会互相覆盖，驱动只返回一个 id 字段，且无法区分来源。
真正安全的做法是：
- 每层子查询独立命名，比如
user_data、admin_list、merged_result - 所有输出列显式重命名：
SELECT id AS user_id, name AS user_name FROM users - 避免依赖位置对齐，尤其在 UNION 中——列数、类型、顺序必须严格一致
最容易被忽略的一点：列名冲突问题往往在开发环境“侥幸通过”，等上了生产、换了数据库小版本、或者加了一张新表，查询就突然开始返回错误数据，而不是报错。它不声不响，但后果是业务逻辑错乱。
