SELECT常量值时列名不可读是标准行为，因常量无隐式别名；需用AS显式命名，否则易致ORM映射、UNION对齐及类型兼容等问题。

SELECT 常量值时为什么结果列名是问号或空字符串

数据库执行 SELECT 1 或 SELECT 'hello' 时，返回结果的列名往往不可读——PostgreSQL 给 ?column?，MySQL 可能为空，SQL Server 是 (No column name)。这不是 bug，而是标准行为：常量字面量没有隐式别名。

解决办法很简单，但必须显式加 AS：

• SELECT 1 AS user_id → 列名变成 user_id
• SELECT 'active' AS status → 列名是 status
• 不写 AS 也能用空格简写：SELECT 'active' status（多数方言支持，但可读性差）

漏掉别名会导致后续代码（比如 ORM 映射、JSON 序列化、前端取字段）出错，尤其在动态拼 SQL 或 UNION 多个常量查询时，列名对齐会直接失败。

在 UNION 中混用常量和表字段容易列数/类型不匹配

UNION 要求所有子查询列数一致、对应列类型兼容。常量容易悄悄破坏这个规则：

• 错误示例：SELECT id, name FROM users UNION SELECT 1 → 列数不同，报错
• 更隐蔽的错误：SELECT id, 'user' FROM users UNION SELECT 999, 'admin' → 看似没问题，但若 id 是 BIGINT 而 999 被推断为 INTEGER，某些数据库（如 PostgreSQL）会拒绝隐式转换
• 安全做法：对齐列数 + 显式类型转换：SELECT id::TEXT, 'user' FROM users UNION SELECT '999', 'admin'

别依赖数据库自动“猜”类型，尤其跨方言迁移时，SELECT 0 在 SQLite 是整数，在 Oracle 可能被当 NUMBER，但在某些 JDBC 驱动里会被映射成 Boolean。

用常量填充缺失字段时要注意 NULL vs 空字符串语义

想补全数据结构（比如导出固定字段 CSV），常用 SELECT col1, col2, 'N/A' AS source。但这里有个关键取舍：

• 'N/A' 是字符串，不是 NULL；如果下游逻辑靠 IS NULL 判断缺失，它就失效了
• 反过来，用 NULL 常量：SELECT col1, NULL AS source，但某些客户端（如 Excel 导入、某些 BI 工具）会把 NULL 显示为空白，不如 'N/A' 直观
• 数值场景更危险：SELECT 0 AS score 和 SELECT NULL AS score 在聚合（AVG()、SUM()）中行为完全不同

选什么取决于下游怎么消费——先看清楚那个字段在业务里代表“未填写”还是“明确为零/空”，再决定常量值。

SELECT 常量在视图或 CTE 中可能被优化掉，导致意外行为

有些数据库（如 PostgreSQL 14+、SQL Server）会对只含常量的子查询做折叠优化。例如：

WITH base AS (SELECT 1 AS flag) SELECT * FROM base WHERE flag = 1

看起来无害，但若你在 base 里还写了注释或调试用的 RAISE NOTICE（PL/pgSQL），它们可能被整个跳过——因为优化器发现 flag 永远是 1，直接内联常量，不执行子查询体。

所以：

• 不要在纯常量 CTE 里放副作用逻辑（日志、临时表插入等）
• 需要确保执行顺序？加个无害但阻止折叠的表达式：SELECT 1 AS flag, current_timestamp AS ts
• MySQL 8.0 的 CTE 默认递归模式下，常量 CTE 不会触发递归，但名字仍占位，注意命名冲突

这种优化通常不报错，但会让调试变得诡异——你以为某段逻辑执行了，其实根本没跑。