SELECT 'xxx' AS tag在报表中特别有用，因其能轻量补充业务上下文，如标记来源渠道、环境或版本号，不依赖表结构且无JOIN开销；需注意字符串必须加单引号，避免误写为未引号标识符导致报错。
为什么 SELECT 'xxx' AS tag 这种写法在报表里特别有用
直接加常量列是补充业务上下文最轻量的方式，比如导出订单数据时统一标记来源渠道、区分测试/生产环境数据、给结果集打上版本号。它不依赖表结构，也不触发 JOIN 或子查询开销，但容易被当成“没用的硬编码”忽略其业务语义价值。
常见错误是把常量写成未加引号的标识符，比如 SELECT prod AS env，结果数据库报错说列 prod 不存在——其实本意是想写字符串 'prod'。
- 字符串常量必须用单引号包裹，
'prod'是值，prod是列名或别名 - 数字、布尔值可不加引号（如
1、TRUE），但为统一风格和避免歧义，建议全用单引号 - MySQL 和 PostgreSQL 对空字符串
''和 NULL 的处理一致；SQL Server 中空字符串会自动转为 NULL，需注意
多环境 SQL 脚本里怎么安全嵌入环境标记
运维或 BI 同事经常要手动改 SQL 里的环境字段，一不小心就漏改某处，导致测试数据混进生产报表。与其靠人眼检查，不如把环境变量“固化”进查询逻辑本身。
示例：在所有查询结果末尾加一列 env_flag 标识当前执行环境：
SELECT order_id, amount, 'prod' AS env_flag FROM orders WHERE created_at > '2024-01-01';
关键点：
- 别名
env_flag要有意义，避免用flag、type这类泛化词，后续做 UNION 或导出到 Excel 时才不会歧义 - 如果脚本要在不同环境复用，建议把常量抽成变量（如 PostgreSQL 的
\set env '''prod'''+SELECT ... :env AS env_flag），而不是靠查找替换 - 某些 BI 工具（如 Tableau）会把全相同值的列自动折叠或隐藏，测试时务必展开结果集确认该列真实存在
UNION 多个数据源时如何对齐常量列避免类型冲突
合并来自不同表或不同业务线的数据时，常量列是区分来源的最简方式，但各子查询的常量类型不一致会导致 UNION 失败。比如一个写 'ios'，另一个写 android（漏了引号），PostgreSQL 就会报错：UNION types text and unknown cannot be matched。
- 所有参与 UNION 的常量列必须显式保持类型一致：统一用
'ios'、'android'，不要混用1和'1' - 如果某分支需要 NULL 占位（比如某表没有对应渠道信息），写成
CAST(NULL AS TEXT)，而不是裸写NULL（其类型由上下文推断，易错） - SQL Server 对长度敏感：
'web'是varchar(3)，'backend_service'是varchar(16)，UNION 时会取最长的，但若中间有varchar(max)就可能拖慢性能
常量列在 GROUP BY 和 ORDER BY 中的陷阱
常量列不能单独出现在 GROUP BY 子句中（除非 SELECT 里只有它），否则多数数据库会报语法错误；但它可以出现在 ORDER BY 中控制整体排序位置，这点常被忽略。
- 错误写法：
SELECT 'total' AS scope, SUM(sales) FROM t GROUP BY 'total'→ 报错，应写成GROUP BY scope或直接去掉 GROUP BY（因常量无分组意义） - 合理用法：
ORDER BY 'priority_high', created_at DESC可强制所有结果排在最前，适合做汇总行置顶 - 注意：MySQL 5.7 兼容模式下允许
GROUP BY 'xxx'，但升级到 8.0+ 默认禁用，提前适配可避免上线失败
真正麻烦的不是怎么写常量列，而是当别人接手你的 SQL 时，是否能一眼看出这个 'v2.3' 是版本号、还是数据分区标识、抑或是某个已下线功能的遗留标记——加注释比加列名更重要。
