SELECT中同名字段必须用AS重命名，如u.id AS user_id、o.id AS order_id；WHERE不能用SELECT别名，需回退原始引用；视图和子查询须内部重命名；JOIN的ON子句必须带表前缀。
SELECT里两个id字段必须用AS重命名
直接写 SELECT u.id, o.id 会导致结果集列名重复，多数数据库（PostgreSQL、SQL Server）会报错 column "id" specified more than once；MySQL 虽可能执行成功，但只保留最后一个 id，且顺序不可控，应用取值时极易拿错数据。
- 必须显式用
AS给每个同名列赋予唯一别名：u.id AS user_id、o.id AS order_id - 别名不能只是
id AS id——这仍是重复，没解决问题 - 缩写要一致：如果表别名是
u和o，就该用user_id和order_id，别混用usr_id或ord_id - 即使某字段当前无冲突（如
o.amount），也建议统一加别名，避免后续加表后突然失效
WHERE和ORDER BY不能用SELECT里的AS别名
WHERE 子句根本看不到 SELECT 中定义的别名，因为 SQL 执行顺序是 FROM → WHERE → GROUP BY → SELECT → ORDER BY。写了 SELECT u.status AS user_status，再写 WHERE user_status = 'active' 必报错 Unknown column 'user_status'。
-
WHERE中必须回退到原始引用：WHERE u.status = 'active'或WHERE users.status = 'active' -
ORDER BY在标准 SQL 中允许用SELECT别名，但不推荐依赖——有些驱动或旧版本 MySQL 行为不一致 - 复杂表达式（如
COALESCE(u.phone, u.email)）若需在WHERE过滤，只能重复写一遍，或改用子查询提前算好并命名
视图和子查询里重命名必须在内部完成
视图或子查询一旦返回同名列，外部就无法区分。比如 (SELECT id, name FROM users) u JOIN (SELECT id, name FROM admins) a，外层 SELECT * 必崩，因为结果集已“扁平化”，原始表信息丢失。
- 视图定义中每个输出列都必须带
AS：CREATE VIEW v_user_order AS SELECT u.id AS user_id, a.id AS admin_id - 子查询也一样：
(SELECT id AS user_id, name AS user_name FROM users) u，不能指望外层补救 - 聚合字段如
COUNT(*)同样需要别名：COUNT(*) AS total_count，否则后续查v.total_count会失败 - 别名是视图的对外契约——改基表字段名、换数据库版本（如 MySQL 5.7 → 8.0），只要视图定义没同步更新，就可能立刻出错
JOIN的ON子句漏表前缀会直接报错或逻辑错乱
ON 是关联逻辑的唯一定义位置，不加表前缀会导致数据库无法解析字段归属。写 ON user_id = id，而 users 和 orders 都有 id，就会触发 Column 'id' in on clause is ambiguous 错误，或更糟——隐式匹配出错，导致笛卡尔积或漏关联。
-
ON中所有字段必须带表别名前缀：ON o.user_id = u.id，左右两边都不能省 - 即使某字段只在一张表存在（如
orders.status），也建议加前缀——防止后续加新表引入同名字段后突然失效 - 自然连接（
NATURAL JOIN）看似省事，实则更危险：它自动按同名列匹配，表结构一变（比如新增updated_at），行为就失控
AS 的查询就可能立刻崩。 
