coalesce子查询参数必须返回单值，否则报错；每个子查询均会执行一次，存在性能与一致性风险；应加limit 1、类型显式转换，并优先用cte或isnull/ifnull优化。
子查询作为COALESCE参数时必须确保单值返回
COALESCE的每个参数都必须是标量值（即一行一列），如果子查询返回多行或多列，会直接报错，比如SQLCODE -378或subquery must return only one column。这不是COALESCE的问题，而是子查询本身不满足上下文要求。
- 正确写法：用
(SELECT name FROM users WHERE id = 1)——带括号、结果唯一 - 错误写法：
SELECT name FROM users WHERE status = 'active'（没括号，且可能多行） - 更隐蔽的坑：子查询里用了
ORDER BY但没LIMIT 1，即使业务上“应该只有一条”，数据库仍可能报错或警告 - PostgreSQL和SQL Server对“多行子查询”的报错更严格；MySQL在某些模式下会静默取第一行，但行为不可靠，别依赖
COALESCE包裹子查询时注意执行次数
COALESCE按顺序短路求值，但**每个子查询参数都会被完整执行一次**——哪怕前面的子查询已返回非NULL值。这是关键性能陷阱，尤其当子查询含JOIN或聚合时。
- 例如
COALESCE((SELECT COUNT(*) FROM orders WHERE user_id = u.id), (SELECT COUNT(*) FROM legacy_orders WHERE user_id = u.id))，即使第一个子查询有结果，第二个仍会被执行 - SQL Server明确文档指出：含子查询的COALESCE参数可能被计算多次，结果不稳定（如隔离级别变化导致两次查询返回不同值）
- 解决办法：把子查询提前放到CTE或派生表中，再用COALESCE选值，例如
WITH precalc AS (SELECT u.id, ...) - 如果必须用子查询兜底，优先考虑
ISNULL（SQL Server）或IFNULL（MySQL），它们对子查询只计算一次，但牺牲了多参数灵活性
嵌套子查询 + COALESCE 的典型安全写法
常见需求是“从关联表查主联系方式，查不到就 fallback 到默认值”。这时不能让COALESCE直接包裸子查询，而要控制空值来源。
- 错误示范：
COALESCE((SELECT phone FROM contacts WHERE user_id = u.id), '未提供')——若子查询无匹配行，返回NULL，COALESCE生效；但若子查询因权限/锁失败，可能报错而非返回NULL - 更稳妥写法：
COALESCE(NULLIF((SELECT phone FROM contacts WHERE user_id = u.id LIMIT 1), ''), '未提供')，先用NULLIF把空字符串转为NULL，再兜底 - 强烈建议加
LIMIT 1（PostgreSQL/MySQL）或TOP 1（SQL Server），避免隐式多行风险 - 如果子查询可能返回NULL或根本无记录，用
COALESCE((SELECT ...), 'fallback')是安全的；但如果子查询本身可能报错（如字段不存在、权限不足），COALESCE无法捕获异常，需靠应用层或存储过程处理
跨数据库兼容性：子查询参数的类型一致性
COALESCE要求所有参数类型兼容。子查询返回类型由其SELECT列表决定，容易和字面量类型冲突。
- 例如
COALESCE((SELECT created_at FROM logs WHERE id = 1), 'N/A')在PostgreSQL会报错：timestamp vs text不兼容 - 修复方式：显式
CAST或TO_CHAR，如COALESCE(TO_CHAR((SELECT created_at ...), 'YYYY-MM-DD'), 'N/A') - MySQL相对宽松，会尝试隐式转换，但结果不可控（比如timestamp转成0或'0000-00-00'）
- 最保险做法：所有子查询返回同一大类类型（全字符串、全数值、全日期），兜底字面量严格匹配——
'N/A'配字符串子查询，0配数值子查询
