必须显式指定JOIN后SELECT字段的表来源，如t1.id、t2.id，并用带表前缀的别名（如user_id、order_id）避免歧义；ON和GROUP BY中所有字段也须加表前缀，否则报错或数据错乱。
JOIN后SELECT字段名重复导致报错或数据错乱
直接用 SELECT * 或多个表里都有 id、name 这类通用字段时，数据库会报错（如 MySQL 8.0+ 的 Column 'id' in field list is ambiguous），或者查询结果里字段被覆盖、取值不可控。
根本原因不是语法不允许，而是 SQL 执行时无法分辨你指的到底是哪张表的 id。不加限定，就等于让数据库猜——它不猜，只报错。
- 必须对所有可能重名的字段显式指定来源，哪怕只有一处用到
JOIN - 别依赖“当前没报错就没事”：加个新字段、换数据库版本、改个查询顺序都可能突然崩
-
SELECT t1.id, t2.id可以，但SELECT id, id绝对不行；即使你心里清楚哪个是哪个，SQL 不认“心里清楚”
AS别名命名必须带表前缀才真正安全
很多人写 SELECT u.id AS id, o.id AS id，以为加了 AS 就解决冲突了——其实没用。多数客户端和 ORM（比如 Python 的 psycopg2、Java 的 JDBC）只认最终列名，两个 AS id 仍会覆盖，只剩最后一个生效。
真正能防冲突的命名方式，是把表逻辑嵌进别名里，比如 u.id AS user_id、o.id AS order_id。这不是为了好看，是让下游代码能稳定映射字段。
- 别用
AS id1、AS id2这类无意义序号，后期维护时根本不知道谁是谁 - 如果表名缩写是
usr和ord，对应别名就该是usr_id、ord_id，保持缩写一致性 - ORM 自动生成的 SQL（如 Django 的
select_related）通常不加前缀，上线前务必检查生成语句，手动补别名
LEFT JOIN里ON条件字段未加表前缀引发隐式类型转换
写 LEFT JOIN orders ON user_id = id 看似省事，但一旦 users.user_id 是 BIGINT、orders.id 是 INT，MySQL 可能悄悄做类型转换，导致索引失效、查询变慢几倍。
更糟的是，某些数据库（如 PostgreSQL）会直接拒绝这种写法，报 column reference "user_id" is ambiguous —— 它比 MySQL 更早拦住你。
- 所有
ON里的字段，必须带表别名，如ON u.user_id = o.user_id - 别图快在
ON里用*或函数包裹字段（如ON DATE(created_at) = '2024-01-01'），这会让索引完全失效 - 如果关联字段命名不一致（比如
users.uid↔orders.owner_id），就在ON里写全，别指望靠别名统一
GROUP BY + 多表JOIN时字段来源必须显式声明
GROUP BY id 在单表里没问题，但一加 JOIN，数据库就不知道这个 id 是分组依据还是普通字段。PostgreSQL 直接报错，MySQL 5.7+ 严格模式下也报错：Expression #1 of SELECT list is not in GROUP BY clause。
这不是兼容性问题，是 SQL 标准要求：所有非聚合字段，必须出现在 GROUP BY 中，且必须明确属于哪张表。
-
GROUP BY u.id才合法，GROUP BY id不行，哪怕只有u.id存在 - 如果要按用户地区分组，而地区字段在
profiles表里，就得写GROUP BY p.region，不能写GROUP BY region - SELECT 里的聚合字段（如
COUNT(*)）不用出现在 GROUP BY，但所有其他字段都得列出来并带前缀
status 别名撞车，这种事真发生过。 
