SELECT中直接写字符串或数字即为常量列，是标准SQL行为，所有主流数据库均支持；常量可与表字段结合输出固定值，需注意别名引号规则、NULL类型推断及隐式转换风险，并广泛用于数据合并、维度补全和调试等场景。
SELECT 中直接写字符串或数字就是常量列
SQL 的 SELECT 语句允许在字段列表里直接写字面量，比如 'abc'、42、NULL，它们会作为常量值出现在每一行结果中。这不是“技巧”，而是标准行为，所有主流数据库（PostgreSQL、MySQL、SQL Server、SQLite）都支持。
常见错误是误以为必须用函数或伪列（如 Oracle 的 DUAL），其实只要不加表名/别名引用，直接写就生效：
SELECT 'active' AS status, 100 AS price, user_id FROM users;
这会为 users 表的每一行生成固定值 'active' 和 100。
给常量列起别名时注意引号和关键字冲突
别名如果含空格、特殊字符或碰上保留字（如 order、group、user），必须用引号包裹。不同数据库引号规则不同：
- PostgreSQL / SQL Server：用双引号
"order_status" - MySQL：可用反引号
`order`，或开启 ANSI 模式后用双引号 - SQLite：双引号或方括号
[user]
没加引号却用了关键字，会报错，例如：SELECT 'pending' AS order FROM orders 在 MySQL 中会失败——order 是保留字。
NULL 和类型隐式转换容易引发意外
常量列的类型由数据库根据字面量推断，但跨列混合时可能触发隐式转换，尤其在 UNION 或视图定义中：
-
SELECT '1' UNION SELECT 1：有些库返回字符串，有些转成数字，结果列类型不一致 -
SELECT NULL AS flag：该列类型为 unknown，后续WHERE flag = 1可能因类型不匹配失效 - 显式 cast 更安全：
CAST(NULL AS INTEGER) AS flag或CAST('2024-01-01' AS DATE)
特别是写 INSERT … SELECT 或导出到下游系统时，类型模糊会导致解析失败或精度丢失。
常量列在复杂查询中的实际用途
它不是玩具语法，真实场景中高频用于：
- 合并多张结构相似但来源不同的表：
SELECT *, 'sales' AS source FROM sales_2023 UNION ALL SELECT *, 'sales' AS source FROM sales_2024 - 补全缺失维度：ETL 中临时加
'daily'作为统计粒度标识 - 构造调试数据：
SELECT 1 AS id, 'test' AS name, CURRENT_DATE AS created_at快速验证下游逻辑 - 配合 CASE 生成派生状态：
CASE WHEN amount > 100 THEN 'high' ELSE 'low' END AS level本质也是常量表达式
注意：常量列不会减少扫描行数，也不会提升性能——它只是结果集的一列输出。别指望靠它“优化”查询，但它能让逻辑更清晰、避免重复写死值。
