nvl能填充null但不改变分组逻辑，group by中null始终自成一组；正确写法是group by nvl(col, 'val')，且需注意跨数据库函数差异、count陷阱、索引优化及decode/case替代场景。
GROUP BY 里遇到 NULL，NVL 真能“填”上吗？
能填，但填得不彻底——NVL 只影响聚合前的值，不影响分组逻辑本身。NULL 在 GROUP BY 中永远自成一组，NVL(col, 'unknown') 后，那一组就变成 'unknown' 这个非 NULL 值，但原始 NULL 行仍不会被合并到其他组。
- 常见错误现象：
SELECT NVL(status, 'pending') AS s, COUNT(*) FROM orders GROUP BY status—— 分组仍按原始status（含 NULL）执行，NVL的结果只是 SELECT 列别名，对分组无作用 - 正确写法必须把
NVL放进GROUP BY：GROUP BY NVL(status, 'pending') - 注意 Oracle 特性：
NVL是 Oracle 专属，PostgreSQL 用COALESCE，MySQL 用IFNULL或COALESCE，跨库迁移时这里必报错
用 NVL 处理 COUNT 时的空值陷阱
COUNT(col) 本就不统计 NULL，所以对它套 NVL 没意义；但如果你想要「把 NULL 当 0 算进总数」，就得换思路。
- 错误示范：
COUNT(NVL(amount, 0))——COUNT统计的是非 NULL 行数，NVL把 NULL 变成 0 后，0 仍是有效值，这行照样被计入，结果和COUNT(*)一样 - 真正需要的是条件计数：
SUM(CASE WHEN amount IS NULL THEN 1 ELSE 0 END)或更直接：COUNT(*) - COUNT(amount) - 如果目标是「金额为 NULL 的订单，按 0 参与 SUM」，才该用：
SUM(NVL(amount, 0))
NVL 嵌套在聚合函数里，性能有啥影响？
影响很小，但不可忽略——Oracle 会在聚合前逐行计算 NVL，若列上没索引、数据量大，且 NVL 被用于 GROUP BY，会导致无法走索引范围扫描，降级为全表扫描。
- 场景举例：对一个无索引的
category字段做GROUP BY NVL(category, 'other')，即使只有 5% 行是 NULL，也可能让整个分组变慢 3 倍以上 - 优化建议：如果 NULL 比例高且稳定，考虑建函数索引：
CREATE INDEX idx_cat_nvl ON orders (NVL(category, 'other')) - 注意：函数索引只在查询中使用完全相同的表达式时才生效，写成
NVL(category, 'OTHER')（大小写不同）或加额外括号都会失效
替代方案：什么时候该放弃 NVL，改用 DECODE 或 CASE？
当你要的不是简单“填 NULL”，而是按 NULL / 非 NULL 做不同聚合逻辑，NVL 就力不从心了。
-
NVL只支持两值替换（原值 / 替代值），而DECODE和CASE可处理多分支，比如：DECODE(status, NULL, 'empty', 'A', 'active', 'I', 'inactive', 'unknown') -
CASE更通用，且标准 SQL 兼容性好；DECODE是 Oracle 特有，但解析稍快一点（差别微乎其微） - 容易踩的坑：在
CASE中漏写ELSE，遇到未覆盖值会返回 NULL，可能引发下游逻辑误判——务必显式写ELSE 'default'
NULL 分组这事，最麻烦的不是语法怎么写，而是你得先想清楚：那个 NULL 到底代表“缺失”“无效”还是“尚未发生”——选错填充值，后面所有聚合都跟着偏。
