WHERE中不能使用SELECT定义的别名，因为SQL执行顺序为FROM→WHERE→SELECT，WHERE执行时别名尚未生成；子查询表别名仅在自身作用域内有效，不可被同级或外层直接引用；嵌套中重用外层表别名会导致字段解析歧义，应严格隔离作用域并显式限定前缀。
WHERE里为什么用不了SELECT中定义的别名
因为SQL执行顺序中，WHERE在SELECT之前就完成了。你在SELECT salary * 12 AS annual_salary里声明的annual_salary，到WHERE annual_salary > 100000这步时根本还没生成——解析器直接报Unknown column 'annual_salary' in 'where clause'。
常见翻车写法：SELECT price * qty AS subtotal FROM orders WHERE subtotal > 100 → 报错
- 解决方法只有两个：把表达式原样复制进
WHERE（WHERE price * qty > 100），或包一层子查询再过滤 -
ORDER BY和HAVING（配合GROUP BY时）是少数能直接用SELECT别名的地方 - 别名作用域不跨子句，只对当前
SELECT列表、ORDER BY、HAVING有效
子查询表别名为什么不能被同级其他子查询引用
出现在FROM中的子查询必须带表别名，这是所有主流数据库（MySQL/PostgreSQL/SQL Server）的硬性要求。但这个别名只绑定到该子查询本身，不会“泄漏”给同级的其他子查询使用。
典型错误：SELECT t1.id FROM (SELECT id FROM users) t1, (SELECT t1.id FROM orders) t2 → t1.id在第二个子查询里不可见
- 每个子查询是独立解析单元，
t1只在第一个子查询的FROM上下文中存在 - 想跨子查询传值？得靠
JOIN显式关联，或把逻辑上提一层用WITH（CTE）组织 - MySQL 8.0+ 对这种误引用会直接报
Unknown table 't1'，比早期版本更严格
嵌套子查询里重用外层表别名为什么会出问题
子查询内部如果用了和外层相同的表别名（比如外层是users u，子查询里又写SELECT * FROM users u），会导致字段解析歧义——数据库按“最近作用域”规则匹配，u.id会被认为指子查询里的u，而非外层那个。
例如：SELECT u.name FROM users u WHERE u.id IN (SELECT u.id FROM orders u) → 子查询里的u.id实际指向orders.id，不是users.id
- 避免重用：子查询改用
o、ord等新别名，和外层u明确隔离 - 字段引用务必带前缀：
u.id不能简写成id，否则多表场景下极易撞名 - PostgreSQL 默认大小写敏感，
AS "U"和AS u会被视为不同别名；MySQL虽不敏感，但混用仍易引发维护混乱
MySQL里看似能重用别名其实是解析器“越界查找”
MySQL有个非标准行为：在SELECT列表的子查询里，它会尝试向上查找外层SELECT定义的列别名（如(SELECT c1)能识别前面定义的c1）。但这不是SQL标准，而是MySQL解析器的特殊实现——它先查子查询本地，查不到就往外层SELECT列表里找。
危险示例：SELECT CONCAT(a,b) AS c1, (SELECT c1) FROM (SELECT 'x' a, 'y' b) t → 能运行，但PostgreSQL和SQL Server直接报错
- 别依赖这个行为：它没写进SQL标准，文档里也无保证，升级或换库就崩
- 真正可靠的写法是把计算逻辑前置，或用
WITH把c1定义为命名结果集 - 复杂嵌套中，别名作用域边界非常脆弱，最稳的方式是每层都显式重命名输出列，并用表别名限定访问路径
