标量子查询必须返回单值，否则报错；应优先用where精确限定、coalesce处理null、left join替代以提升性能；null比较需显式判断；exists更适用于存在性判断。
标量子查询必须返回单值，否则直接报错
在 CASE 表达式里嵌套子查询时，SQL 引擎会严格校验该子查询是否为“标量”——即最多返回一行一列。一旦子查询返回多行（比如漏写 WHERE 或关联条件不唯一），就会抛出类似 Subquery returned more than 1 value（SQL Server）或 Single-row subquery returns more than one row（Oracle）的错误。
实操建议：
- 始终在子查询末尾加
LIMIT 1（PostgreSQL/MySQL 8.0+）或TOP 1（SQL Server），但要意识到这属于兜底手段，掩盖了逻辑缺陷 - 优先通过
WHERE精确限定，例如用主键、唯一约束字段做关联：(SELECT name FROM users u WHERE u.id = orders.user_id) - 对可能为空的场景，用
COALESCE包裹子查询，避免CASE分支因 NULL 被跳过：COALESCE((SELECT status_name FROM status_map WHERE code = o.status), 'unknown')
CASE WHEN 中调用子查询的性能代价很高
每行数据执行一次子查询，等于把 O(n) 操作变成了 O(n×m) —— 如果外层扫描 10 万行，子查询平均扫描 100 行，就是千万级扫描。尤其在 MySQL 5.7 或早期版本中，这类写法几乎无法走索引下推。
实操建议：
- 确认子查询是否真的需要动态计算：如果映射关系静态且有限（如状态码转中文），优先用
CASE WHEN o.status = 1 THEN '已支付' WHEN o.status = 2 THEN '已发货'... - 若映射表较大或需复用，改用
LEFT JOIN预加载，比在CASE里反复查快一个数量级 - PostgreSQL 用户可考虑用
LATERAL子查询替代，支持更可控的执行计划
MySQL 与 PostgreSQL 对标量子查询的 NULL 处理逻辑不同
当子查询无匹配结果时，MySQL 返回 NULL；PostgreSQL 同样返回 NULL，但某些旧版本（如 9.x）在严格模式下可能报错。更关键的是：在 CASE 中比较 NULL 时，WHEN (SELECT ... ) = 'A' 永远不成立（因为 NULL = 'A' 结果为 UNKNOWN），容易导致默认分支被意外触发。
实操建议：
- 显式判断子查询结果是否为
NULL：WHEN (SELECT code FROM dict WHERE id = t.type) IS NOT NULL AND (SELECT code FROM dict WHERE id = t.type) = 'A' - 更安全的做法是把子查询提取到
FROM子句，用别名引用，避免重复执行和 NULL 陷阱 - 在 MySQL 中开启
sql_mode=STRICT_TRANS_TABLES可提前暴露空结果问题
用 EXISTS 替代值比较能规避 NULL 和多行风险
如果业务逻辑本质是「判断某类记录是否存在」而非取具体值（例如“是否 VIP 客户”），用 EXISTS 写法比标量子查询更健壮：它天然只关心真假，不依赖返回值，也不怕多行或 NULL。
示例对比：
-- 危险：依赖值，可能多行或 NULL CASE WHEN (SELECT level FROM vip_users v WHERE v.user_id = o.user_id) = 'SPECIAL' THEN '尊享' ELSE '普通' END <p>-- 安全：只判存在性 CASE WHEN EXISTS (SELECT 1 FROM vip_users v WHERE v.user_id = o.user_id AND v.level = 'SPECIAL') THEN '尊享' ELSE '普通' END</p>
这种写法绕开了标量约束，执行计划也更容易优化，适合权限、标签、黑白名单等二元判断场景。
真正难的不是写出能跑的语句，而是想清楚：这个映射是静态规则、小表关联，还是必须实时查大表？选错路径，后期加索引都救不回来。
