视图中空值必须在定义时用COALESCE显式处理，否则查询结果仍为NULL；COALESCE跨库兼容、支持多参数且类型更稳健，而IFNULL仅限MySQL，NVL为Oracle专用且隐式转换易出错。
视图里的空值不会自动填充，必须在定义视图的 SELECT 语句中显式用 COALESCE 或 IFNULL 包裹字段——否则前端查出来还是 NULL，连字符串拼接都会整个变 NULL。
定义视图时必须在 SELECT 列表里用 COALESCE 填充
视图只是保存查询逻辑，不存储数据，所以空值处理必须写死在 SELECT 子句里。不能指望“查视图的时候再加 COALESCE”，那等于每次调用都得重写一遍。
- 正确写法：
CREATE VIEW user_summary AS SELECT id, COALESCE(nickname, name, '访客') AS display_name, COALESCE(phone, '未绑定') AS contact FROM users;
- 错误写法：只写
nickname和phone，寄希望于下游应用处理——结果报表里出现NULL、JSON 接口字段消失、前端模板报错 - 注意类型一致性：如果
nickname是TEXT，name是VARCHAR(50)，默认值写'访客'没问题；但若字段是INT（比如score），填'0'在 PostgreSQL 会报错，得写0或显式CAST
LEFT JOIN 视图中右表字段为 NULL 的典型表现
视图含 LEFT JOIN 时，右表字段天然为 NULL，但很多人只对字段做 COALESCE，却忽略聚合或分组后逻辑被扭曲。
- 常见错误：在视图里写
GROUP BY r.category，但r.category来自右表且可能为NULL，导致NULL自成一组，和COALESCE(r.category, '未知')显示值不一致 - 正确做法：分组键和显示字段表达式必须完全一致，例如
GROUP BY COALESCE(r.category, '未知')+SELECT COALESCE(r.category, '未知') AS category - 更稳妥的思路：不对分组键动刀，而是包裹聚合结果，比如
COALESCE(AVG(o.amount), 0)—— 这样既保留原始分组结构，又避免空组返回NULL
IFNULL 只能在 MySQL 视图里用，跨库迁移会直接报错
IFNULL 是 MySQL/MariaDB 专属函数，PostgreSQL、SQL Server、Oracle 都不认识。一旦视图要迁移到其他数据库，或者用同一套 SQL 跑多套环境，就会失败。
- MySQL 视图可用：
IFNULL(nickname, '游客')，简洁但锁死生态 - 跨库安全写法：
COALESCE(nickname, '游客')，所有主流数据库都支持 - 别混用：
COALESCE(nickname, IFNULL(extra, '备用'))看似灵活，实则增加维护成本，且IFNULL在非 MySQL 环境下根本跑不起来 - 强类型数据库（如 PostgreSQL）还会校验参数类型：若
nickname是INT，COALESCE(nickname, '游客')会报类型不兼容，必须写COALESCE(nickname::text, '游客')或统一转文本
WHERE 条件里误用 COALESCE 导致索引失效
视图定义里如果在 WHERE 子句用了 COALESCE(status, 'active') 这类表达式，数据库通常无法使用 status 字段上的索引，查询会变慢，尤其数据量大时。
- 错误示例：
WHERE COALESCE(status, 'active') = 'active'—— 看似想查“状态是 active 或 NULL 的记录”，但执行计划里索引大概率失效 - 高效等价写法：
WHERE status IS NULL OR status = 'active'，能走索引，语义也更清晰 - 同理，
ORDER BY COALESCE(created_at, NOW())也会让排序无法利用created_at索引，应改用ORDER BY created_at NULLS LAST（PostgreSQL）或ORDER BY IFNULL(created_at, '9999-12-31')（MySQL）
最易被忽略的一点：视图里用了 COALESCE，不代表下游查询就安全了。如果视图被嵌套引用（比如 A 视图 SELECT B 视图），而 B 视图没做空值处理，A 视图里的 COALESCE 就拦不住源头的 NULL。空值处理必须从最底层视图开始逐层兜住。
