表别名是多表JOIN的刚性需求，非可选优化；因同名列（如id、name）会导致结果错乱或静默丢弃，必须用u、o等短别名限定所有字段及ON条件，并为子查询强制命名，否则语法报错。
表别名不是可选的“锦上添花”，而是多表 JOIN 场景下避免列名冲突、提升可读性和防止解析错误的刚性需求。
为什么必须用表别名？——列名重复直接导致结果错乱
当两张表都有 id 和 name 字段时，不加表别名的 SELECT id, name FROM users JOIN orders ON users.id = orders.user_id 会返回两个同名列。多数数据库驱动（如 PostgreSQL 的 pg、MySQL 的 mysql2）只保留第一个 id 和第一个 name，第二个被静默丢弃。应用层拿到的数据结构可能和你预期完全不符，且无报错提示。
正确做法是强制为每张表指定唯一短别名，并在所有列引用前带上它：
-
users表用u，orders表用o - 所有字段写成
u.id、u.name、o.id、o.status - ON 条件里也必须用别名：
ON u.id = o.user_id，不能写ON users.id = orders.user_id
表别名的写法差异：AS 可省略，但引号规则不能错
FROM users AS u 和 FROM users u 在 MySQL、PostgreSQL、SQL Server 中都合法；但别名本身若含空格、连字符或为保留字（如 order、user），就必须加引号：
- MySQL：用反引号
`my-table`或双引号"my table" - PostgreSQL / SQL Server：只认双引号
"my table"，单引号会报syntax error at or near "as" - 别名
user在 PostgreSQL 中必须写成"user"，否则解析器会把它当成系统函数
子查询必须有别名，否则语法报错
所有子查询出现在 FROM 子句中时，数据库要求必须显式命名，否则直接拒绝执行：
SELECT * FROM (SELECT user_id, COUNT(*) c FROM orders GROUP BY user_id) AS order_counts;
这里 order_counts 是强制的。漏掉 AS order_counts 或只写 order_counts（无 AS），PostgreSQL 报 subquery in FROM must have an alias，MySQL 报 Every derived table must have its own alias。这个限制无法绕过，也不建议用视图替代——临时子查询更轻量、意图更明确。
别名作用域只在当前查询层级，嵌套时容易混淆
表别名的作用范围仅限于它所在的查询块。在 CTE 或外层查询中定义的别名，内层子查询不能直接使用：
WITH user_orders AS (SELECT u.id, o.status FROM users u JOIN orders o ON u.id = o.user_id) SELECT id FROM user_orders WHERE status = 'shipped';
上面没问题；但如果写成：
SELECT u.id FROM users u WHERE u.id IN (SELECT user_id FROM orders WHERE status = 'shipped');
内层子查询里的 u.id 就非法了——u 在子查询里根本不可见。这时候要么重复写 users 表名，要么把条件提到 JOIN 里。最容易被忽略的是 ORM 自动生成 SQL 时对别名作用域的误判，尤其在 Django 的 annotate() + filter() 组合中，常因跨层级引用别名导致 column does not exist。
