不能，where执行顺序早于select，无法识别as定义的别名；需在where中重复原表达式或用子查询/cte；distinct作用于整行而非单列；使用*易引发字段冲突、性能下降和兼容性问题；order by可引用别名但需注意null处理与类型转换。
SELECT 子句里能用别名过滤吗？不能，WHERE 看不见 AS 定义的字段
很多人写 SELECT name AS full_name FROM users WHERE full_name LIKE '%John%'，结果报错或查不到数据——因为 WHERE 执行顺序早于 SELECT，它根本不知道 full_name 是啥。
-
WHERE在逻辑上发生在SELECT之前，只能引用原始字段（如name）、表达式或常量，不能引用AS别名 - 真要按拼接后结果过滤，得把表达式原样写进
WHERE：比如WHERE CONCAT(first_name, ' ', last_name) LIKE '%John%' - 如果表达式复杂（比如带函数、多表字段），重复写两遍容易出错；这时可考虑子查询或 CTE，但要注意性能开销
DISTINCT 是去整行重复，不是单列去重
SELECT DISTINCT country FROM customers 没问题，但 SELECT DISTINCT country, city FROM customers 返回的是“country+city”组合唯一的结果，不是每个 country 只取一条。
- 想查“每个国家只返回一个城市”，
DISTINCT不管用，得用GROUP BY country配合MIN(city)或窗口函数 -
DISTINCT会强制对结果集做全字段哈希/排序去重，数据量大时明显拖慢查询，尤其在没索引的字段上 - 某些数据库（如旧版 Access）对
COUNT(DISTINCT column)支持不一致，保险起见可用子查询：SELECT COUNT(*) FROM (SELECT DISTINCT column FROM t) AS tmp
用 * 时要注意多表 JOIN 的字段冲突和隐式膨胀
SELECT * FROM orders JOIN customers ON orders.customer_id = customers.id 表面省事，实际埋雷。
迅易年度企业管理系统开源完整版
下载
系统功能强大、操作便捷并具有高度延续开发的内容与知识管理系统，并可集合系统强大的新闻、产品、下载、人才、留言、搜索引擎优化、等功能模块，为企业部门提供一个简单、易用、开放、可扩展的企业信息门户平台或电子商务运行平台。开发人员为脆弱页面专门设计了防刷新系统，自动阻止恶意访问和攻击；安全检查应用于每一处代码中，每个提交到系统查询语句中的变量都经过过滤，可自动屏蔽恶意攻击代码，从而全面防止SQL注入攻击
- 一旦两表有同名字段（比如都叫
id），*会让结果集出现两个id，多数客户端或 ORM 会丢掉其中一个，且不报错 - 加新字段后查询结果结构可能突变，前端解析容易崩；尤其在 Access 或旧版 MySQL 中更常见
- 真正需要所有字段时，明确写出表前缀更安全：
SELECT orders.*, customers.name, customers.email - 生产环境强烈建议禁用
*，不只是规范问题——它让执行计划难以优化，还可能拉回大量无用字段增加网络和内存负担
ORDER BY 能用 SELECT 中的别名，但得小心 NULL 和类型隐式转换
SELECT price * qty AS total FROM orders ORDER BY total DESC 是合法的，因为 ORDER BY 是最后执行的阶段之一，能看到 SELECT 的别名。
- 但如果
total是计算字段且含NULL，不同数据库对NULL排序位置处理不同（MySQL 默认排最前，PostgreSQL 默认最后），得显式用ORDER BY total DESC NULLS LAST（如果支持） - 别名若来自字符串拼接（如
CONCAT(a, b)），而a或b是数字类型，某些数据库会触发隐式转换，导致排序结果不符合预期（比如按字符串字典序排数字） - 在分页场景（
LIMIT/OFFSET）中，ORDER BY字段必须有确定性顺序，否则同值记录翻页时可能重复或丢失——加主键作为第二排序条件是常见兜底做法
字段别名看着只是显示问题，但它牵扯执行顺序、类型推导、NULL 处理和跨数据库兼容性。哪怕最简单的 SELECT name AS n FROM t，背后也藏着优化器怎么走、结果怎么归、错误怎么报的整条链路。
