SQL如何给查询结果起别名？利用AS提升列名可读性
SELECT 中给列起别名必须用 AS 吗？
先说结论：不是必须，但强烈建议你显式地写上 AS。为什么？省略 AS 这个动作，在 MySQL、PostgreSQL 这些主流数据库里确实能蒙混过关，比如 SELECT name AS full_name 和 SELECT name full_name 查出来的结果一模一样。但问题就出在这个“大多数”上——Oracle 数据库可不吃这一套，直接就会给你抛出一个语法错误。更别提 SQLite 这类对空格和特殊字符格外敏感的引擎了。所以，养成显式书写 AS 的习惯，本质上是在为你的 SQL 脚本买一份“跨数据库兼容险”，能有效避免未来迁移时那些令人头疼的隐性故障。
举个例子，下面这个写法就是个典型的坑：SELECT user_name '用户姓名'。在 PostgreSQL 里运行，你会立刻收到一条报错：syntax error at or near "用户姓名"。原因在于，没有 AS 时，数据库会把‘用户姓名’误认为是字符串字面量，而不是一个别名。正确的姿势应该是：SELECT user_name AS "用户姓名"。看到了吗？双引号在这里至关重要，专门用来包裹那些包含中文或空格的别名。
带空格、中文或关键字的别名怎么写？
当别名里想用空格、中文，甚至不小心用了数据库的关键字时，事情就变得稍微复杂一点了。记住一个核心原则：必须用双引号（" "）包裹起来。在 PostgreSQL 和 Oracle 中，这种别名是区分大小写的；而 MySQL 虽然默认不区分，但一旦开启了 ANSI_QUOTES 模式，也得老老实实用双引号。
SELECT COUNT(*) AS "总记录数"—— 包含中文的别名，这么写最安全通用。SELECT price * qty AS "订单金额(元)"—— 别名里带了括号？同样必须请双引号出场。SELECT id AS "order"—— 哪怕你只是想把结果列命名为order（它恰好是个 SQL 关键字），不加引号解析就会失败。- 这里有个关键区分：单引号（
' '）是专门用来表示字符串值的，绝不能用在别名定义上，否则语法错误马上就来。
表别名和列别名能混用吗？要注意什么？
当然可以混用，但这里面的优先级和作用域就像两个不同的工作区，容易混淆。表别名主要在 WHERE、JOIN、GROUP BY 这些子句里发挥作用，用来简化对表名的引用。而列别名呢？它的生效范围通常只在 SELECT 列表和 ORDER BY 子句中。这里有个最常见的陷阱：
SELECT user_id AS uid, name AS uname FROM users WHERE uname = 'Alice'
执行这条语句会报错。原因在于，SQL 的执行顺序里，WHERE 子句的解析早于 SELECT。当数据库引擎处理 WHERE 时，你定义的列别名 uname 还不存在呢！正确的写法应该是直接使用原列名：WHERE name = 'Alice'。
至于表别名，有个不错的实践是使用简短的小写字母或缩写，比如：SELECT u.id, o.amount FROM users u JOIN orders o ON u.id = o.user_id。这样写既清晰明了，又避免了反复书写冗长的原始表名。
AS 在子查询和 CTE 中怎么影响可读性？
到了子查询和公共表表达式（CTE）这里，AS 的角色就更关键了，它直接关系到代码能否正确运行和是否易于理解。
- 子查询：外层查询必须给整个子查询结果集起一个表别名，否则一定会报错。标准写法是：
SELECT t.name FROM (SELECT id, name FROM users) AS t。这里的AS t不可或缺。虽然 MySQL 8.0 之后允许省略AS，写成(...) t，但别名本身必须有。 - CTE：在 CTE 定义中，
AS是语法本身的一部分，绝对不能替换成等号或省略。格式固定为：WITH active_users AS (SELECT * FROM users WHERE status = 'active') SELECT * FROM active_users。 - 当查询嵌套层次较深时，给别名赋予清晰的语义变得尤为重要。用
user_orders这样的名字，远比用t1、t2更利于后期维护和理解。
总而言之，给列起别名看似是 SQL 里最基础的操作之一，但恰恰是跨数据库兼容性、关键字冲突、作用域误用这三点，最容易在系统上线后或跨环境迁移时突然“爆雷”。特别是当 SQL 语句需要被嵌入到应用代码中动态拼接，或者从 BI 工具导出后再进行手动修改时，引号用对了吗、AS 写了吗，这些细节往往就是那条区分执行成功与失败的红线。
