SQL中字符串常量必须用单引号括起，如'SELECT 'admin' AS role'返回值为不带引号的admin；多加引号会报错或转义；数值常量如123不加引号，类型由数据库隐式推断，建议显式CAST确保类型一致。

SELECT中直接写字符串常量会自动带引号吗

不会。SQL里直接写 'hello' 是字符串字面量，结果列值就是不带引号的 hello；写 123 就是数值类型，不是字符串。数据库不会在结果里额外加引号——那是客户端（比如MySQL CLI、DBeaver）为了区分类型而做的显示处理，实际数据没引号。

常见误解：看到结果里显示 'admin' 就以为SQL得写成 '''admin'''，其实完全不需要。多加单引号反而会报错或变成转义字符。

• 正确：SELECT 'admin' AS role FROM users; → 结果列值是字符串 admin
• 错误：SELECT '''admin''' AS role FROM users; → 在PostgreSQL里可能解析为带单引号的字符串 'admin'，在MySQL里直接语法错误
• 数值常量同理：SELECT 99 AS status_code 返回整数，不是字符串 "99"

不同数据库对NULL和类型推断的处理差异

显式写常量时，各数据库对类型和NULL的默认推断不一致，容易导致后续 UNION 或 JOIN 出问题。比如 NULL 在MySQL里默认是 TEXT，在PostgreSQL里是 UNKNOWN，SQL Server里是 INT（取决于上下文）。

• 安全做法：用 CAST(NULL AS VARCHAR(10)) 或 CAST(0 AS BIGINT) 显式指定类型
• MySQL中 SELECT NULL AS flag 的列类型可能是 VAR_STRING，但和 SELECT 'N' AS flag 做 UNION 时一般能隐式转换；PostgreSQL则严格要求类型一致，必须都 CAST
• 避免靠猜：执行 DESCRIBE（MySQL）或 \d（psql）看实际列类型，别只信SELECT结果的显示

在WHERE条件里复用SELECT中定义的常量列名

不能。SQL执行顺序是 FROM → WHERE → GROUP BY → SELECT，所以 SELECT 'active' AS status 定义的 status 列在 WHERE 阶段还不存在，直接写 WHERE status = 'active' 会报错 Unknown column 'status'。

• 想按常量过滤，只能在 WHERE 里重复写值：WHERE user_type = 'premium'，而不是依赖 SELECT 里的别名
• 如果逻辑复杂，考虑用子查询或CTE提前固化：WITH t AS (SELECT *, 'premium' AS tier FROM users) SELECT * FROM t WHERE tier = 'premium';
• 别名能在 ORDER BY 和 HAVING 中使用，因为它们在 SELECT 之后执行

拼接常量与字段时NULL导致整列变NULL

用 ||（PostgreSQL/Oracle）或 CONCAT()（MySQL 5.7+）拼接时，只要任一操作数是 NULL，整个结果就是 NULL。比如 first_name || ' ' || last_name，如果 last_name 是 NULL，结果全丢。

• PostgreSQL/Oracle：用 COALESCE(last_name, '') 替换空值，或改用 CONCAT(first_name, ' ', last_name)（MySQL CONCAT 会跳过 NULL）
• MySQL：优先用 CONCAT() 而非 + 或 ||（后者在MySQL里默认是逻辑OR）
• 常量本身不会NULL，但和字段拼接时字段的NULL会传染——这点容易被忽略，查出来全是空，却找不到原因

常量列看着简单，但类型隐式转换、NULL传播、执行顺序这些点，真正在多表联合或导出到应用层时才暴露问题。别图省事硬写 SELECT 'fixed' AS x, NULL AS y 就完事，先 DESCRIBE 看一眼列类型，再决定要不要 CAST。