在select中直接写常量即可添加固定值列，如select *, 'processed' as status from orders；注意单引号字符串、数字不加引号、别名必须用as，且where/order by不可引用该别名因执行顺序在select之后。
SQL里怎么加一个固定值的列
直接在 SELECT 里写常量就行，不用函数、不用子查询，更不需要临时表。比如你想给每行都加个 'processed' 标签，就写 SELECT *, 'processed' AS status FROM orders。
常见错误是试图用 INSERT INTO ... VALUES 或 UPDATE 去“添加列”，但那是改表结构或数据，不是查结果时加字段。查的时候加常量列，纯属 SELECT 表达式的事。
- 字符串用单引号：
'done'，数字不用引号：1、0.5 - 布尔值因数据库而异：PostgreSQL 支持
TRUE/FALSE，MySQL 用1/0，SQL Server 用1/0或CONVERT(bit, 1) - 别名必须用
AS（或空格），否则某些方言（如 SQL Server）会报错或误解为表别名
不同数据库对 NULL 和类型推断的处理差异
常量列看似简单，但一跨数据库就容易翻车——主要出在类型隐式转换和 NULL 表现上。
比如你写 SELECT id, NULL AS remark FROM users，PostgreSQL 会把 remark 推断为 unknown 类型，遇到 UNION 就可能报错；MySQL 默认当 TEXT；SQL Server 当 INT（因为 NULL 被当成整型上下文）。
- 显式转类型最稳：
CAST(NULL AS VARCHAR(20)) AS remark或'' AS remark（空字符串比裸NULL更可控） - 避免混用：不要在同一个
UNION的两侧用'active'和1做同名常量列，类型冲突大概率报错 - SQLite 对类型宽松，但别依赖——它不校验，上线到其他库就崩
用常量列配合 CASE 或 JSON 构造动态标记
单纯写死一个值太静态，实际中常要按条件输出不同常量，这时候得和 CASE 配合；或者想塞结构化数据（比如固定元信息），就得靠 JSON 函数。
例如给订单打状态标签：SELECT id, amount, CASE WHEN amount > 1000 THEN 'VIP' ELSE 'normal' END AS tier FROM orders；又或者加统一版本标识：SELECT *, '{"version":"2.1","source":"etl"}'::json AS meta（PostgreSQL）。
- MySQL 8.0+ 用
JSON_OBJECT('version', '2.1', 'source', 'etl')，别用字符串拼 JSON，逃逸和引号容易错 -
CASE结果列类型取各分支的“最高优先级类型”，字符串分支里混入NULL一般不会出问题，但混入数字就会强制转字符串，可能多出空格或科学计数法 - 如果常量内容含单引号（比如
'O''Reilly'），记得双写，别用反斜杠——不是所有方言支持
为什么 WHERE 或 ORDER BY 里不能直接引用常量列别名
因为 SQL 执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT，而常量列是在 SELECT 阶段才生成的，所以 WHERE status = 'processed' 会报错——status 此时还不存在。
要么重复写表达式：WHERE 'processed' = 'processed'（无意义但合法），要么用子查询/CTE 包一层，让别名落地后再过滤。
- 子查询写法：
SELECT * FROM (SELECT *, 'processed' AS status FROM orders) t WHERE t.status = 'processed' - CTE 更清晰：
WITH tagged AS (SELECT *, 'processed' AS status FROM orders) SELECT * FROM tagged WHERE status = 'processed' - 别在
ORDER BY里偷懒写序号常量（如1 AS sort_key）然后ORDER BY sort_key——虽然多数库允许，但语义不清，建议直接ORDER BY 1（按第一列）或重写表达式
最常被忽略的是执行顺序导致的别名不可见问题，不是语法糖不够多，是没意识到 SQL 不是自上而下读的代码。
