select *在多表join中会导致字段歧义报错或结果不可靠，必须显式指定带表别名的字段并用as重命名冲突列，on子句中所有字段也须加前缀，严禁natural join和隐式逗号连接。
SELECT列表里直接写*会出什么问题
多数数据库（PostgreSQL、SQL Server）直接报错：column reference "id" is ambiguous；MySQL 5.7+ 默认拒绝执行，旧版虽允许但只保留最后一个同名列的值，且字段顺序不稳定——应用层用row["name"]取值时，根本不确定拿到的是 users.name 还是 orders.name。
这不是“能不能跑”的问题，而是“跑出来能不能信”的问题。临时查数据时手快敲了SELECT * FROM users JOIN orders，一旦两表都有id、created_at，结果就不可靠。
- 永远不要在 JOIN 场景下用
SELECT *，哪怕只是调试 - 想快速预览结构，先用
DESCRIBE users和DESCRIBE orders对比字段 - ORM（如 SQLAlchemy）可能自动加前缀，但原始 SQL 不会——别依赖框架兜底
ON子句中漏写表前缀导致关联逻辑错误
ON user_id = id 这种写法在多表 JOIN 中必然失败。数据库无法判断左边的 user_id 属于哪张表、右边的 id 是 users.id 还是 orders.id。轻则报错 Column 'id' in on clause is ambiguous，重则隐式匹配失败，退化为笛卡尔积或索引失效（尤其当两表同名列类型不一致时，如 BIGINT vs INT）。
- 所有
ON中的字段必须带表别名或全名，例如ON u.id = o.user_id - 即使某字段当前只存在于一张表（如
orders.status），也建议加前缀——防止后续加表后突然崩 - 别用
NATURAL JOIN：它按同名列自动匹配，表结构一动（比如新增updated_at），行为就失控
列别名不是可选装饰，而是消歧义的强制动作
只起表别名（如 FROM users u JOIN orders o）不够。如果 SELECT u.id, o.id 后不重命名，结果集里还是两个叫 id 的列——客户端解析时仍会丢弃或混淆。
正确做法是用 AS 给每个可能冲突的列赋予语义化别名：
SELECT u.id AS user_id, u.name AS user_name, o.id AS order_id, o.amount, o.created_at AS order_created_at FROM users AS u JOIN orders AS o ON u.id = o.user_id;
-
AS在表别名中可省略（FROM users u合法），但在列别名中不能省 - 别用
u.id AS id，这仍和o.id AS id冲突；优先用user_id这类带上下文的名称 - 子查询或视图中必须提前重命名，否则外层无法区分；例如
(SELECT u.id AS user_id FROM users u) t
WHERE 和 ORDER BY 里别名能用吗
WHERE 看不到 SELECT 里的列别名（SQL 执行顺序是 FROM → WHERE → SELECT），所以 WHERE user_id > 100 会报错，必须写成 WHERE u.id > 100。
ORDER BY 可以用别名（标准 SQL 支持），但要保持风格统一：如果 SELECT 用了 u.name AS user_name，那 ORDER BY user_name 就行；但如果 SELECT 没用别名，ORDER BY 就得写 u.name，混用容易出错。
-
GROUP BY必须和SELECT中的非聚合字段严格对应：写了SELECT u.name AS user_name, COUNT(*)，就得GROUP BY user_name（别名可用）或GROUP BY u.name（原始字段） - 复杂表达式（如
COALESCE(u.phone, u.email)）若需在WHERE过滤，得原样重复写一遍，或改用 CTE / 子查询提前计算 - 跨数据库项目（如兼容 MySQL + PostgreSQL）务必按严格模式写：所有字段带前缀，所有别名显式定义
实际中最容易被忽略的点是：别名作用域仅限当前查询层级。子查询里的 u 和外层的 u 无关，视图定义里的别名也不会透传到外部查询——这些地方不重命名，歧义就藏得更深。
