WHERE子句不能使用SELECT别名，因SQL执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY，别名在WHERE之后才生成；须用原始列名或表别名引用，如d.name；跨数据库均不支持WHERE中用别名，解决方法是子查询或CTE。
WHERE子句里用SELECT别名报错，因为执行顺序不支持
SQL标准执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。这意味着WHERE在SELECT之前运行，所有在SELECT中定义的列别名（比如 depName、col1）此时根本还没生成，自然无法被识别。
常见错误现象：
Unknown column 'depName' in 'where clause'Error in SELECT clause: alias not recognized-
Invalid column name 'xxx'（尤其在SQL Server或Visual Database Tools中）
这不是数据库“bug”，而是SQL语义决定的——别名只是结果集的显示标签，不是中间计算的变量名。
JOIN后给字段起别名，WHERE里仍要用原始引用方式
即使你写了 SELECT e.name AS emp_name, d.name AS dep_name FROM employee e JOIN department d ON ...，在WHERE里也不能写 WHERE dep_name = '测试部'。必须回退到原始来源表达式：
- 用表别名 + 原始列名：
WHERE d.name = '测试部' - 或者直接写完整字段表达式：
WHERE d.name = '测试部'（不能省略d.） - 如果涉及函数或计算，WHERE里也得重写一遍：
WHERE UPPER(d.name) = '测试部'，不能依赖AS dep_name_upper
注意：部分数据库（如PostgreSQL）允许在ORDER BY里用SELECT别名，但WHERE和HAVING一律不行——这是跨数据库的硬约束。
ClickHouse和MySQL对别名的一致性要求更严格
ClickHouse会强制要求：一旦在SELECT中定义了别名（如 a.event_type2_id AS event_type2），后续所有子句（GROUP BY、HAVING、ORDER BY）都必须使用该别名，不能混用原始列名。MySQL则相反：它不允许在WHERE或GROUP BY里用别名，但ORDER BY可以。
- ClickHouse报错示例：
HAVING a.event_type2_id > 10→ 必须改成HAVING event_type2 > 10 - MySQL报错示例：
GROUP BY col1（而col1是SELECT x AS col1定义的）→ 必须改成GROUP BY x或用子查询 - 嵌套查询时，外层无法直接引用内层
SELECT的别名，除非显式包裹成派生表
想在过滤条件里用别名？只能靠子查询或CTE
没有捷径，必须把带别名的逻辑提前“固化”成一个结果集，再对外层做条件过滤：
- 子查询方式：
SELECT * FROM (SELECT name AS emp_name FROM employee) t WHERE emp_name = '张三' - CTE方式（推荐可读性）：
WITH emp AS (SELECT name AS emp_name FROM employee) SELECT * FROM emp WHERE emp_name = '张三' - 临时表仅适合复杂多步场景，别为单次过滤建
TEMPORARY TABLE，开销不值
特别注意JPA/Hibernate等ORM场景：框架可能自动拼COUNT语句，若原SQL用了表别名（如 FROM user u），它可能误把u当字段名生成 SELECT COUNT(u)，导致Unknown column 'u'。此时必须显式提供countQuery。
