子查询必须显式声明表别名和字段别名，否则外部引用失败；嵌套层级深时应采用组合式命名并避免重复别名，JOIN和UNION中别名作用域需严格遵循SQL标准。
子查询里别名必须显式声明，不能依赖字段自动推导
SQL标准不支持子查询字段自动作为外部引用名，不写 AS 或空格别名，外部 SELECT 就会报错或取到意外列名。比如 (SELECT user_id FROM orders WHERE status = 'paid') 在外面用 t1.user_id 会失败——因为没给子查询起表别名，更没给字段定义别名。
- 子查询必须带表别名：
(SELECT user_id FROM orders WHERE status = 'paid') AS paid_orders - 关键字段建议显式命名：
(SELECT u.id AS user_id, u.name AS user_name FROM users u) AS u_info - 避免用数字或纯下划线开头的别名（部分方言如 PostgreSQL 允许但 MySQL 会警告）
嵌套层级超过两层时，别名要体现数据来源路径
三层以上嵌套（比如主查 → 子查 → 子子查）会让别名迅速失去可读性。用缩写拼接方式比单纯用 t1/t2 更可靠，比如订单统计中「用户-订单-订单项」链路，别名可以是 u、o、oi，而不是全用 t1～t3。
- 推荐组合式命名：
(SELECT ... FROM (SELECT ...) AS o_items) AS o_summary，其中o_items表明是订单项聚合，o_summary是其上层汇总 - 避免在不同嵌套层重复使用同一别名（如内外都叫
u），MySQL 会按最近作用域解析，容易误引用 - PostgreSQL 支持列别名在子查询内直接定义，但跨层引用仍需表别名支撑，不可省略
JOIN 中混用子查询别名，注意 ON 条件里的作用域限制
当子查询作为 JOIN 右表出现时，ON 子句能访问的字段仅限于左右两侧当前层级的别名，不能跳级访问子查询内部未暴露的字段。
- 错误写法：
FROM users u JOIN (SELECT order_id, user_id FROM orders) o ON u.id = o.user_id✅ 可行；但若子查询里没选user_id，只写了SELECT order_id FROM orders，则ON u.id = o.user_id直接报错column o.user_id does not exist - 别名大小写敏感性取决于数据库：MySQL 默认不敏感，PostgreSQL 默认敏感，
AS "UserTable"在 PG 里必须用双引号引用才能匹配 - 如果子查询含聚合（如
COUNT(*)），必须为结果字段显式命名，否则ON中无法引用：SELECT COUNT(*) AS cnt FROM ...
UNION 后的子查询别名只作用于整个结果集，不能用于单个分支
UNION 各分支是独立执行单元，每个分支的 AS 只在该分支内有效；最终结果集的别名才是外部可见的唯一入口。
- 下面写法合法：
(SELECT id, name FROM users UNION SELECT id, title FROM posts) AS combined_list，外部只能用combined_list.id - 不能这样写：
(SELECT id AS uid FROM users) UNION (SELECT id AS pid FROM posts)，两个AS互不影响，且外部无法区分字段来源 - 字段数和类型必须严格一致，别名不参与校验——哪怕左边叫
uid、右边叫pid，只要都是整型，UNION就通过，但外部只能用第一个分支的字段名（uid）来引用
JOIN 条件里的旧别名，查出来的数据就 quietly 错了。 
