加表名或别名前缀可解决ERROR 1052歧义问题，因MySQL严格遵循SQL标准，要求多表同名列必须明确归属；SELECT、GROUP BY、ORDER BY均需统一使用带前缀或别名的字段。
直接加表名或别名前缀就能解决，不加就报 ERROR 1052 (23000): Column 'id' in field list is ambiguous。这不是 MySQL 的 bug，是它在认真执行 SQL 标准——多个同名列必须明确归属。
为什么 SELECT 中的字段会歧义
只要两个表里有同名字段（比如 id、name、create_time），又没写清楚来源，MySQL 就没法决定你指哪个。哪怕当前只有 users 有 id，orders 还没加该字段，一旦后续加了，原来能跑的 SQL 就立刻报错。
- 常见组合：users + orders（都有
id）、products + categories（都有name）、logs + users（都有created_at） - 子查询也一样：外部查
employees.name，子查询又返回name，不加别名就会冲突 - 错误信息里一定带具体列名和错误码
1052，这是定位依据，别跳过
SELECT、GROUP BY、ORDER BY 必须统一用法
别以为只在 SELECT 加前缀就够了。GROUP BY 和 ORDER BY 引用的字段，如果存在歧义，同样会炸。MySQL 5.7+ 默认开启 ONLY_FULL_GROUP_BY，更严格。
- 正确写法：
SELECT u.id, u.name, COUNT(o.id) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id, u.name ORDER BY u.created_at DESC - 错误写法：
GROUP BY id或ORDER BY name—— 没带前缀，也不对应SELECT中的别名 - 如果
SELECT用了别名（如u.name AS user_name），ORDER BY就得写user_name；如果没用别名，就必须写u.name
别名不是可选项，是生产环境强制项
用 AS 给表起短别名（u、o、p）不只是为省事，是让整条语句可读、可维护、抗变更。
- 别名要简短但有含义：不要用
a、b，优先u（users）、o（orders）、li（line_items） - 字段别名建议加
_后缀区分来源：u.id AS user_id、o.id AS order_id，避免应用层取值时混淆 - JOIN 多于 3 张表时，不加别名的 SQL 很快就没人敢改——光数点号都容易漏
- ORM 拼 SQL 或 MyBatis 动态 SQL 里也得同步处理别名，否则运行时才暴露问题
最常被忽略的一点：视图、存储过程、定时任务里的旧 SQL，可能多年没动过，但只要关联表结构微调（比如新增同名列），就会突然报 1052。上线前用 EXPLAIN 或简单 SELECT 1 验证下关键查询，比等监控告警再救火强得多。
