多表JOIN时SELECT *会因列名歧义被主流数据库直接报错；必须显式指定字段并用表别名+AS重命名，如u.id AS user_id，且ON、WHERE、ORDER BY等子句均需统一使用带前缀的原始字段名。
多表 JOIN 时 SELECT * 直接报错：列名歧义是硬性限制
多数主流数据库（PostgreSQL、SQL Server、MySQL 8.0+、ClickHouse）在多表 JOIN 场景下，遇到 SELECT * 会立即拒绝执行，错误信息类似：Column 'id' is ambiguous 或 ambiguous column reference。这不是警告，是语法层面的拦截——数据库压根不给你机会运行下去。
原因很简单：两张表都有 id、name、created_at，SELECT * 没法决定结果集中该保留哪个 id，也无法保证字段顺序稳定。MySQL 5.7+ 默认禁用歧义 *；ClickHouse 从 19.5 版本起直接禁用多表 JOIN 下的 SELECT *。
- 别信“我本地能跑”，换环境、升版本、加一张新表，立刻崩
- 即使旧版 MySQL 暂时容忍，
row["name"]取到的是哪张表的值，完全取决于查询计划，不可控 - ORM（如 SQLAlchemy）可能帮你加前缀，但原始 SQL 不会兜底——出问题时你得自己改
SELECT * 在 JOIN 中引发的隐性数据错乱
比报错更危险的是“看似成功却返回错数据”。当数据库没报错（如某些 MySQL 配置下），它可能只保留最后一个同名列，或按内部顺序拼接字段。应用层用 row["status"] 读取时，你以为拿到的是 orders.status，实际可能是 users.status，而这个差异在线上可能持续数周才被发现。
-
SELECT *让字段归属彻底丢失，调试时无法反推来源表 - 后续加表、改表结构（比如
products.updated_at和orders.updated_at同时存在），查询逻辑瞬间失效 - 视图或子查询中用
SELECT *，等于把歧义封装进元数据，下游所有引用都继承风险
ON 子句漏表前缀：比 SELECT * 更致命的错误
ON user_id = id 这种写法不是“省事”，是让数据库失智。它无法判断 user_id 属于左表还是右表，id 是 users.id 还是 orders.id。轻则报错，重则退化成笛卡尔积或索引失效。
- 必须写成
ON u.id = o.user_id或ON users.id = orders.user_id，两边字段都带前缀 - 哪怕某字段当前只存在于一张表（如
orders.payment_method），也建议加前缀——防止加新表后突然冲突 -
NATURAL JOIN更糟：它按同名列自动匹配，表结构一动（比如新增updated_at），关联逻辑就失控
正确写法：显式 + 别名 + 语义化
唯一可靠的做法，是放弃 SELECT *，转为显式声明每个字段，并用表别名和 AS 给出无歧义的输出名。
例如：
SELECT u.id AS user_id, u.name AS user_name, o.id AS order_id, o.status AS order_status, o.created_at AS order_created_at FROM users u LEFT JOIN orders o ON u.id = o.user_id
- 表别名用语义缩写（
u、o），不用t1、t2——嵌套三层后根本没法维护 - 每个同名字段必须用
AS重命名，u.id AS user_id是标准，u.id user_id虽语法允许但易读性差、易漏看 -
WHERE和ORDER BY里不能用AS别名（SQL 执行顺序决定它们还不可见），必须用原始带前缀的字段名或统一在子查询中封装
复杂点在于：一旦开始用别名，就得全链路保持一致——ON、SELECT、GROUP BY、ORDER BY，少一个环节就可能出错。这不是风格选择，是执行层面的刚性约束。
