当前位置:首页 > AI技术 > 正文内容

AS关键字输出字段名称最佳实践|Duuu笔记

admin1周前 (03-31)AI技术17

AS别名在SQL中需用引号包裹含空格/特殊字符的名称,ORDER BY可有限使用别名而GROUP BY不可,表别名AS可省略但视图/CTE中必须,别名影响视图接口与下游兼容性。

SELECT 中用

AS

给字段起别名,但别名里不能有空格或特殊字符

直接写

SELECT name AS full name

会报错,因为

full name

被解析成两个标识符。MySQL、PostgreSQL、SQL Server 都一样。

解决方法只有两种:

AS "full name"

(双引号,PostgreSQL/SQL Server 支持)或

AS `full name`

(反引号,MySQL 专用)。SQLite 用双引号,Oracle 用双引号但要求别名全大写才不报错。

别名含空格、连字符、中文时,必须加引号包裹,否则语法错误

别名不含特殊字符时,

AS

可省略,

SELECT name fullname

是合法的,但可读性差,不推荐

别名是临时的,不影响原表结构,也不影响后续

WHERE

GROUP BY

—— 它们只能引用原始列名或表达式,不能用别名(除非在子查询或 CTE 里)

ORDER BY

GROUP BY

中能不能用

AS

别名?

不能直接用 —— 大多数数据库(MySQL 5.7+、PostgreSQL、SQL Server)在

ORDER BY

中允许用别名,但在

GROUP BY

中不行。Oracle 和老版本 MySQL 甚至

ORDER BY

也不认。

比如

SELECT user_id, COUNT(*) AS cnt FROM logs GROUP BY cnt

会报错:

ERROR: column "cnt" does not exist

。因为

GROUP BY

执行早于

SELECT

列计算,别名还没生成。

ORDER BY

是唯一可能“认”别名的地方,但靠不住,建议统一用原始列或位置序号(如

ORDER BY 2

GROUP BY

必须写原始列名、表达式,或重复整个聚合表达式(如

GROUP BY user_id, COUNT(*)

不合法,得写

GROUP BY user_id

想按别名分组?包一层子查询:

SELECT * FROM (SELECT user_id, COUNT(*) AS cnt FROM logs) t GROUP BY t.cnt

AS

给表起别名时,为什么有时候写

JOIN users u

JOIN users AS u

更常见?

因为表别名的

AS

关键字在所有主流 SQL 方言中都是可选的,而且省略后更紧凑。写

FROM orders o JOIN users u ON o.user_id = u.id

是标准实践,加

AS

反而显得冗余。

Action Figure AI

借助Action Figure AI的先进技术,瞬间将照片转化为定制动作人偶。

下载

但注意:如果表名是关键字(比如叫

order

),又用了别名,那

AS

就不能省 ——

FROM order o

会语法报错,必须写

FROM order AS o

或换引号:

FROM `order` o

表别名不用

AS

是惯例,不是规范强制,但团队协作时保持一致更重要

视图或 CTE 中定义别名时,

AS

是必须的,比如

WITH active_users AS (SELECT * FROM users WHERE status = 'active')

嵌套子查询里,别名不可省略,且必须跟在右括号后:

(SELECT id FROM logs) AS sub

,漏掉

AS

在 PostgreSQL 和 SQL Server 会报错

AS

别名在视图和导出场景下的实际影响

创建视图时用

AS

定义的字段名,会成为视图的“公开列名”。下游应用查这个视图时看到的就是别名,不是原始列名。这点容易被忽略,尤其当原始列名带下划线(

created_at

)而别名用驼峰(

createdAt

)时,前端代码可能直接依赖后者。

导出 CSV 或对接 BI 工具时,别名会作为表头输出。但如果用了引号包裹的别名(如

AS "User Name"

),某些旧版工具可能无法识别空格,导致字段错位。

视图中别名一旦定下,就该当作接口契约维护;改别名等于破坏下游兼容性

BI 工具或 ORM 映射时,优先读取列名而非注释,所以别名比注释更关键

别名长度受限:SQL Server 最长 128 字符,MySQL 是 64 字节(中文算多字节),超长会被截断且无警告

别名看着只是改个名字,但它在执行顺序、跨方言兼容、下游消费三个层面都藏着隐性约束。最常踩的坑不是不会写,而是写了之后没意识到它在哪能用、在哪不能用、以及改了会影响谁。

相关文章

使用 ESP

针对该分类问题,我们使用了 Kaggle 手势识别数据集 中的一个开源数据集。原始数据集包括 10 个类别,我们只使用了其中 6 个。这些类别更容易识别,且日常生活中更有用,如...

神经网络中的单层神经网络

神经网络是一种模拟人脑的神经网络以期能够实现类人工智能的机器学习技术。人脑中的神经网络是一个非常复杂的组织。成人的大脑中估计有1000亿个神经元之多。 看一个经典的神经网络。这是一个包...

推荐10个AI人工智能技术网站

除了研究和开发人工智能技术,OpenAI还积极参与人工智能伦理和安全的研究和探讨。 认为,人工智能技术的发展必须遵循伦理和法律的规范,以确保人工智能的应用不会对人类带来负面影响。...

跨平台机器学习:ML.NET架构及应用编程

平台上的一个机器学习框架,它提供了一套丰富的算法和工具,使得开发人员可以轻松地构建和部署机器学习模型。支持多种编程语言,包括等,这使得它成为跨平台机器学习的理想选择。的架构主要包括三个部分:数据读取、...

一文讲清神经网络、BP神经网络、深度学习的关系

人工神经网络中的顶级代表。往往说《神经网络》就是指《BP神经网络》。 大家研究着各种神经网络,研究得不亦乐乎, 来了两个家伙Romelhart 和Mcclelland,...

深入理解优化:如何利用 Gemini 3.1 的阶梯计费策略?企业级大规模调用实务完全指南|Duuu笔记

需深入理解Gemini 3.1阶梯计费与调用联动关系,通过识别阶梯区间、请求级Token预估截断、多模型路由调度、响应缓存去重、项目拆分配额绑定五种路径优化成本。 ☞☞☞AI 智能聊天, 问答助手,...

发表评论

访客

看不清,换一张

◎欢迎参与讨论,请在这里发表您的看法和观点。