为什么SQL中多表JOIN时尽量避免使用SELECT *？-SQL-PHP中文网

多表JOIN时SELECT *会因列名歧义被主流数据库直接报错；必须显式指定字段并用表别名+AS重命名，如u.id AS user_id，且ON、WHERE、ORDER BY等子句均需统一使用带前缀的原始字段名。

为什么sql中多表join时尽量避免使用select *？

多表 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