create view时必须对select字段逐个coalesce，因视图不存数据、只存逻辑，未处理null会导致下游报表空值、json缺键、concat结果为null；数值需注意cast精度，字符串拼接须内层coalesce；left join后group by须与select表达式一致；where/order by中用coalesce会失效索引；跨库迁移唯一兼容写法是coalesce；nullif语义相反不可替代；兜底动作必须在create view的select中显式完成。
CREATE VIEW时必须对SELECT字段逐个COALESCE
视图不存储数据，只保存查询逻辑；你在定义里没处理NULL，下游拿到的就是原始NULL——报表字段空、JSON序列化缺键、CONCAT拼接整行变NULL。别指望它“自动转空字符串”或“跳过计算”。
常见错误：SELECT id, nickname, phone FROM users → 下游写CONCAT(nickname, ' - ', phone)，任一为NULL，结果就是NULL。
- 正确做法：每个字段显式兜底，如
COALESCE(nickname, '访客')、COALESCE(phone, '未绑定') - 数值字段注意类型精度，避免隐式转换失败：
COALESCE(score, CAST(0 AS DECIMAL(5,2))) - 字符串拼接不能只包外层：
CONCAT(COALESCE(first_name, ''), ' ', COALESCE(last_name, ''))，不是CONCAT(COALESCE(first_name || ' ' || last_name, ''))
LEFT JOIN后字段NULL引发分组错乱
LEFT JOIN天然产生右表字段为NULL，但很多人只在SELECT里用COALESCE，却忘了GROUP BY键必须和显示值一致。否则NULL自成一组，“未知”却无法匹配。
典型错误：LEFT JOIN categories r ON u.category_id = r.id，然后写GROUP BY r.category + SELECT COALESCE(r.category, '未知') → 实际分组键是NULL，显示却是'未知'，聚合结果对不上。
- 正确做法：分组键与SELECT表达式完全相同，如
GROUP BY COALESCE(r.category, '未知')+SELECT COALESCE(r.category, '未知') AS category - 更稳妥替代：不对分组键动刀，改用聚合后兜底，如
COALESCE(AVG(o.amount), 0) AS avg_amount - 若右表关联键无索引，还可能因JOIN失效导致意外
NULL，记得检查r.id是否有索引
WHERE或ORDER BY里用COALESCE会破坏索引
COALESCE放在SELECT列里是安全的；但塞进WHERE或ORDER BY（比如WHERE COALESCE(status, 'N') = 'Y'），数据库无法利用status上的索引，大表上执行计划常从Index Scan退化为Seq Scan。
- 性能影响真实存在，尤其在千万级订单表上，响应延迟可能从毫秒级升到秒级
- 业务真需按“兜底后值”筛选，优先考虑在源表加计算列并建索引，如
ALTER TABLE orders ADD COLUMN status_fallback AS (CASE WHEN status IS NULL THEN 'N' ELSE status END) - 或改用
CASE WHEN status IS NULL THEN 'N' ELSE status END = 'Y'，部分引擎（如PostgreSQL 14+）能更好下推优化 - 视图本身不该承担过滤职责，WHERE条件尽量下推到基表
跨库迁移时IFNULL/ISNULL直接报错
IFNULL是MySQL/MariaDB专属，ISNULL是SQL Server专属；PostgreSQL、Oracle、DuckDB等一律不认。一旦视图含IFNULL(phone, '未绑定')，迁移到PG就会报function ifnull does not exist。
- 唯一跨库兼容写法是
COALESCE(phone, '未绑定')，所有主流引擎都支持 - 别用
NULLIF替代COALESCE来兜底，NULLIF是“相等则转NULL”，语义相反 - 如果必须兼容老系统且不能改SQL，可在应用层做方言适配，但视图定义层坚持用
COALESCE
最易被忽略的一点：视图里的NULL不会因为“下游用了COALESCE”就消失——它从定义那一刻起就决定了暴露形态。处理动作必须落在CREATE VIEW的SELECT子句里，且每个字段、每个使用场景都要单独评估兜底策略。
