必须显式指定列名或使用表别名加前缀消歧义，禁止在JOIN中使用SELECT *；ON子句和SELECT列表均需用别名.列名明确来源，避免列名冲突导致数据丢失或报错。
JOIN后SELECT * 导致列名重复怎么办
直接用 SELECT * 做多表 JOIN 时，只要两张表有同名列（比如都叫 id 或 name），结果集就会出现重复列名——多数客户端（如 MySQL CLI、Python 的 cursor.fetchall()）会丢弃靠后的同名列，或抛出 ProgrammingError: Column 'xxx' in field list is ambiguous。
这不是数据库“不支持”，而是 SQL 标准要求显式消歧义。解决方式只有两个：不用 *，或者给冲突列加前缀/别名。
- 永远避免在 JOIN 场景下写
SELECT *，哪怕只是临时查数据 - 如果必须快速预览，先用
DESCRIBE或SHOW COLUMNS FROM看两表结构，手动比对重名列 - 某些 ORM（如 SQLAlchemy）默认生成带前缀的列名，但原始 SQL 不会自动做这事
用表别名 + 点号引用列是最安全的写法
给每个表起简短别名（如 t1, u, o），再用 别名.列名 显式指定来源，既防冲突，也提升可读性。别名不是可选装饰，是 JOIN 的基本操作规范。
示例：用户表 users 和订单表 orders 都有 id 和 created_at
SELECT u.id AS user_id, u.name, o.id AS order_id, o.amount, o.created_at AS order_created_at FROM users AS u JOIN orders AS o ON o.user_id = u.id;
-
AS在表别名中可省略（FROM users u合法），但列别名不能省 - 列别名优先级高于原始列名，
u.id AS id仍可能和o.id AS id冲突，所以建议用语义化别名（如user_id） - 别名作用域仅限当前查询，不影响原表结构，也不影响后续
WHERE或ORDER BY中的引用
ON 子句里不加前缀一定会报错
ON 是 JOIN 的核心条件，这里列名必须能唯一定位到某张表，否则数据库无法解析关联逻辑。不加表前缀或别名，只要列名在多表中存在，就触发 Column 'xxx' in on clause is ambiguous 错误。
- 错误写法：
ON user_id = id（id在users和orders里都有） - 正确写法：
ON o.user_id = u.id或ON orders.user_id = users.id - 即使某列只在一张表中存在（如
orders.status），也建议加前缀——防止后续加表时突然失效
自然连接（NATURAL JOIN）看起来省事，实际更危险
NATURAL JOIN 会自动按同名列匹配，表面看不用写 ON，但一旦表结构微调（比如新增一个同名字段），行为就不可控。它隐式依赖列名一致性，且无法控制哪些列参与匹配。
- 它等价于
JOIN ... USING (col1, col2, ...)，但列列表由数据库扫描决定，不透明 - MySQL 中
NATURAL JOIN会自动去重同名列，但 PostgreSQL 要求所有同名列类型严格一致，否则报错 - 线上环境几乎从不使用；CI/CD 流水线里如果跑
NATURAL JOIN，很可能某次 schema 变更后查询就静默错乱
列名冲突不是语法边缘问题，而是 JOIN 查询的起点门槛。少打几个字母省下的时间，往往不够排查一次“为什么数据少了一半”所花的功夫。
