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 不会触发递归，但名字仍占位，注意命名冲突
这种优化通常不报错，但会让调试变得诡异——你以为某段逻辑执行了，其实根本没跑。
