必须为表起别名：JOIN、子查询、自连接中不加别名会导致歧义报错（如Column 'name' ambiguous）、语法错误（Not unique table/alias）或强制要求（Every derived table must have its own alias），且影响可读性与维护性。
直接说结论：不给表起别名在简单单表查询里无所谓，但只要涉及 JOIN、子查询或重复引用同一张表，就必须起别名——否则容易写错、读不懂、执行报错，而且越往后维护越痛苦。
为什么 JOIN 语句里不加别名会立刻出问题
最典型的现象是：执行时报错 Column 'name' in field list is ambiguous。这是因为两张表都有 name 字段，SQL 引擎根本分不清你要查哪张表的 name。
实操建议：
- 只要
FROM或JOIN出现两张及以上表，每张表都必须带别名（哪怕只用一次） - 别名不能是 SQL 关键字，比如
order、group、user—— 即使加了反引号也容易埋坑 - 别名尽量用有意义的缩写，比如
orders o比orders a更易定位；但别过度追求“语义”，cust、prod、cat这类通用缩写足够清晰 -
AS关键字可省略：FROM customers c和FROM customers AS c效果完全一样，省掉更干净
子查询和自连接场景下，别名不是可选，是强制语法要求
比如你想查“每个员工的直属上级姓名”，就得把 employees 表连自己两次：一次当员工，一次当上级。这时候不用别名，SQL 直接语法报错。
常见错误现象：
- 写
SELECT name FROM employees JOIN employees ON ...→ 报错Not unique table/alias: 'employees' - 子查询没取别名：
SELECT * FROM (SELECT id, name FROM users)→ 报错Every derived table must have its own alias
实操建议：
- 自连接必须用不同别名，比如
e1和e2，且ON条件里所有字段都得带上别名前缀 - 子查询必须有别名，哪怕只是
t或sub，否则 MySQL / PostgreSQL 都不认 - 嵌套多层子查询时，外层别名要能区分层级，比如
user_orders、order_summary，避免全用t1/t2导致后期无法回溯
别名太短或太随意，反而降低可维护性
很多人图快全用单字母：a、b、c，结果两周后自己再看，完全想不起 a 是哪个表。这不是简化，是自我设障。
性能与兼容性影响很小，但可读性落差极大：
- 单字母别名在团队协作中基本等于“无注释”，别人要猜、要翻建表语句、要试运行
- 长别名（如
customer_order_details_final_view）虽然安全，但写起来累，还可能触发某些 ORM 的截断或映射异常 - 推荐折中策略：2–3 字缩写 + 业务上下文，比如
co（customer order）、inv（inventory）、log（audit log） - 如果表名本身就很短（如
users、posts），直接用u、p问题不大；但像transaction_history_archive这种，至少得缩成tha或trans_hist
真正容易被忽略的是：别名一旦定下来，就该当作接口契约来对待。改 SQL 时如果只改了 FROM 别名却漏改 SELECT 或 WHERE 里的前缀，轻则查不到数据，重则静默返回错误结果——这种 bug 很难被测试覆盖，只能靠写的时候盯紧每一处引用。
