COALESCE参数类型不一致会隐式提升精度导致下游截断，必须显式CAST统一类型；其返回类型由参数优先级决定而非首非NULL值；在WHERE中误用会混淆连接语义；索引视图中需确保所有参数确定性；聚合后兜底可能掩盖“无数据”语义，应优先在展示层处理。
COALESCE参数类型不一致会悄悄改掉字段精度
视图字段类型在创建时就固化了，不是运行时动态推导的。COALESCE返回类型由所有参数按类型优先级隐式决定，而不是“取第一个非NULL值的类型”。比如COALESCE(price, 0)在price是DECIMAL(18,2)时看似安全，但加个999.999就会升格为DECIMAL(18,3)，下游BI工具可能把123.45截成123.4。
必须显式统一类型：
- 数值列：写成
COALESCE(CAST(price AS DECIMAL(18,2)), 0.00) - 字符串列：写成
COALESCE(CAST(name AS VARCHAR(100)), 'N/A')，别信COALESCE(name, 'N/A')“看起来一样” - 日期列：禁止混用字面量，
COALESCE(modified_date, '1900-01-01')在SQL Server中会被转成DATETIME且精度丢失；应写COALESCE(modified_date, CAST('1900-01-01T00:00:00' AS DATETIME2))
LEFT JOIN后用COALESCE兜底，但别混淆语义
COALESCE(t2.status, 'pending')只影响最终输出，不改变t2是否匹配的事实。最容易踩的坑是把它当条件用——比如在WHERE里写COALESCE(t2.status, 'pending') = 'pending'，这会把t2没匹配上的行（原本t2.status为NULL）也拉进来，但同时也把t2匹配上但status确实是'pending'的行混在一起，逻辑已失真。
真正想筛选“t2未关联或status为空”的场景，应该分开写：
立即学习“前端免费学习笔记（深入）”；
- 用
ON条件控制连接逻辑 - 用
WHERE t2.status IS NULL OR t2.status = 'pending'明确表达意图 - 兜底展示仍可用
COALESCE，但仅放在SELECT列表里
索引视图里COALESCE报错？先查参数是否确定性
COALESCE本身是确定性函数，SQL Server允许它出现在索引视图中——但前提是所有参数都必须确定性。一旦你写COALESCE(created_at, GETDATE())或COALESCE(status, NEWID())，整个表达式立刻被判定为非确定性，建索引视图直接失败。
验证方法很简单：
- 执行
SELECT OBJECTPROPERTY(OBJECT_ID('YourView'), 'IsDeterministic')，返回0就说明有问题 - 用常量代替运行时函数：
COALESCE(created_at, '1900-01-01T00:00:00')安全，但格式必须匹配目标列类型 - 如果业务真需要动态默认值（比如当前批次时间），别塞进视图定义，改用计算列+触发器，或交给应用层补全
聚合字段里用COALESCE前先确认NULL是否该被忽略
SUM、AVG、COUNT(col)这些聚合函数天然忽略NULL，这是设计行为，不是bug。如果你在SELECT里对聚合结果再套COALESCE(SUM(amount), 0)，看起来稳妥，但要注意：如果整组数据全为NULL，SUM返回NULL，COALESCE兜底为0；可如果业务上“全NULL”本应代表“无数据”，那返回0反而掩盖了事实。
更稳妥的做法：
- 先用
COUNT(*)和COUNT(col)对比，确认是否有有效数据 - 用
CASE WHEN COUNT(col) = 0 THEN NULL ELSE SUM(col) END保留语义 - 前端展示层再统一处理NULL，而非在视图里强行抹平
视图的核心职责是准确反映数据关系，不是替业务做解释。兜底逻辑越靠近展示层，越容易随需求变化而调整，也越不容易引发下游误读。
