SQL中COALESCE函数详解：轻松处理数据查询中的NULL值难题-代码聚汇网

SQL中COALESCE函数详解：轻松处理数据查询中的NULL值难题

COALESCENULL值SQL函数

|难度：普通|阅读约 38 分钟

NULL 这个值，我愿称之为 SQL 开发里最防不胜防的暗坑。你辛辛苦苦写完一条查询，逻辑没问题，语法没问题，结果报表页面上突然冒出一个刺眼的空白，前端同事跑来问你“这个字段为啥是空的”，你打开数据库一看，明明那行数据存在，就是某个字段的值是 NULL。更麻烦的是，NULL 还会传染——字符串拼接里混进一个 NULL，整个结果直接变 NULL；SUM 聚合里碰上一组全 NULL 的数据，返回值直接让你报表工具报错。COALESCE 函数就是专门用来收拾这种局面的。

COALESCE 是 SQL 标准里的一个函数，核心作用一句话就能说清：接收一串参数，从左往右找，返回第一个不是 NULL 的值。如果你的数据里有大量可空字段，或者你经常写报表、做数据补全、处理 LEFT JOIN 之后出现 NULL 的字段，这篇文章值得你花几分钟读完。我会从函数本身的机制讲起，再展开实际业务里最常用的几个场景，包括和 NULLIF 这些函数的组合玩法，不同数据库下的行为差异，最后用一次我真实遇到过的报表排查经历收尾。哪怕你之前完全没用过 COALESCE，看完也能直接上手。

1. COALESCE 的函数机制：参数列表怎么取值，语义细节在哪里

1.1 函数签名与执行逻辑

COALESCE 的语法极其简单，就一行：

sql复制COALESCE(expr1, expr2, ..., exprn)

函数接收至少两个参数，按书写顺序逐个判断，返回第一个非 NULL 的那个。如果所有参数都是 NULL，它就返回 NULL，绝不自己造值。

这个逻辑可以用一个特别生活化的场景来记忆：你有一个紧急联系人列表，从上到下依次是老婆、老爸、老张、同事小李。系统挨个打电话，第一个接电话的人就是 COALESCE 的返回值。如果四个人全没接，那就返回“无人接听”，也就是 NULL。

有两个细节容易被忽略。第一，参数的顺序是有优先级的，越靠前的参数优先级越高，所以你想要哪个值“优先”被选中，就把它放在前面。第二，COALESCE 不要求所有参数类型完全一样，但数据库会根据类型推导规则做隐式转换，这在不同数据库里行为不一样，后面我会单独讲。

1.2 最小可运行示例

先看几个最基础的查询，方便你理解执行逻辑：

sql复制-- 返回 'A'，因为第一个非 NULL 值就是 A
SELECT COALESCE(NULL, NULL, 'A', 'B') AS result;

-- 返回 0，NULL 被跳过
SELECT COALESCE(NULL, 0, 1) AS result;

-- 返回 NULL，因为所有参数都是 NULL
SELECT COALESCE(NULL, NULL) AS result;

第一条语句返回 A，不会继续往后判断 B。第二条返回 0，因为 0 不是 NULL，这里恰好说明了一个容易搞混的点：COALESCE 不会区分 0 和“有意义的值”，只要不是 NULL 它就认。第三条返回 NULL，因为没有任何参数能兜底。

实际业务里你不会这么傻乎乎地写常量，更多是拿它包字段，比如这样：

sql复制SELECT
    user_id,
    COALESCE(nickname, '未设置昵称') AS display_name
FROM user_profile;

这条 SQL 的意思就是：nickname 字段如果被填了，就显示原本的内容；如果没填（NULL），就显示“未设置昵称”。这是 COALESCE 最常见的用法，没有之一。

1.3 和 ISNULL、IFNULL、NVL 的关系对照

刚开始学这个函数的人，十有八九会被一堆名字搞晕：SQL Server 里有 ISNULL，MySQL 里有 IFNULL，Oracle 里有 NVL，PostgreSQL 里也有 COALESCE。它们都是“取第一个非 NULL 值”的意思，但细节上各有区别。

函数名	支持数据库	参数个数	功能说明
COALESCE	SQL 标准，几乎所有数据库	2个及以上	返回第一个非 NULL 参数
ISNULL	SQL Server / SQLite	2个	两个参数，第一个为 NULL 返回第二个
IFNULL	MySQL	2个	两个参数，第一个为 NULL 返回第二个
NVL	Oracle	2个	两个参数，第一个为 NULL 返回第二个

最关键的区别就在参数个数上：COALESCE 能一口气接收多个参数，做多级回退；而 ISNULL、IFNULL、NVL 都只能二选一，想做“A 是 NULL 就取 B，B 是 NULL 就取 C”这种逻辑，就得自己嵌套一层。

比如在 SQL Server 里：

sql复制-- 用 ISNULL 做多级回退，必须手动嵌套
SELECT ISNULL(phone, ISNULL(email, account)) AS contact_info;

-- 用 COALESCE 写，一句搞定，看起来干净很多
SELECT COALESCE(phone, email, account) AS contact_info;

这也是我强烈建议跨数据库开发的人统一用 COALESCE 的原因：它是标准语法，换数据库基本不用改 SQL。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 业务 SQL 里最常用的几类 COALESCE 场景

2.1 空值显示为默认值

这个场景最常见，前面的昵称示例就是典型。再比如订单表里有的订单还没发货，ship_time 字段是 NULL，前端展示订单列表时希望显示“待发货”，你可以在 SQL 层直接解决：

sql复制SELECT
    order_id,
    COALESCE(ship_time, '待发货') AS ship_status
FROM orders;

这种做法的最大好处是把数据兜底逻辑收敛在 SQL 层，后端代码不需要再写一堆 if 判断。尤其是报表系统或者 BI 工具直接连数据库的场景，SQL 返回什么，页面就显示什么，SQL 不处理，前端就得处理。大多数前端处理 NULL 的姿势又五花八门，容易出现“有的页面显示 -，有的页面显示空字符串”这种不一致问题。

当然有一种情况我不建议在 SQL 里做：业务上需要区分“值为空”和“有默认值”的场合。比如用户性别字段，NULL 表示“用户没填”，0 表示“保密”，1 表示“男”，2 表示“女”，这时候直接用 COALESCE(sex, 0) 会把“没填”和“保密”混为一谈，可能会影响统计。这种时候应该保留 NULL 的语义，等业务层去判断。

2.2 多字段回退：联系方式里的优先级逻辑

COALESCE 最典型的应用场景，是从多个可选字段里按优先级取第一个非 NULL 值。我举一个 CRM 系统里经常出现的例子。

假设有一张用户联系表，设计时为了兼容不同用户群体，同时保留三个字段：phone、email、account。有些用户注册时只填了手机号，有些用户只填了邮箱。你现在的需求是：给每个用户找出一条“当前最佳联系方式”，优先级是手机号 > 邮箱 > 账号 > 最后提示无。

sql复制SELECT
    user_id,
    COALESCE(phone, email, account, '暂无联系方式') AS contact_final
FROM user_contact;

这一条 SQL 就完成了四层回退逻辑。如果换成 CASE WHEN，写法会非常啰嗦：

sql复制SELECT
    user_id,
    CASE
        WHEN phone IS NOT NULL THEN phone
        WHEN email IS NOT NULL THEN email
        WHEN account IS NOT NULL THEN account
        ELSE '暂无联系方式'
    END AS contact_final
FROM user_contact;

不是说 CASE WHEN 不好，而是这种连续判断“哪个字段不是 NULL”的场景，COALESCE 的语义更直白，代码也更短。我在实际项目里见过有人为了不用 COALESCE，写了六层嵌套的 CASE WHEN，可读性差到没人敢改，后来重构时全部换成 COALESCE，SQL 一下子清爽了。

2.3 字符串拼接时防止 NULL 污染

这个坑我猜不少人踩过。你用字符串拼接字段时，只要其中一个字段是 NULL，整个结果就会变成 NULL。

在 SQL Server 里：

sql复制SELECT first_name + ' ' + last_name AS full_name FROM users;

如果某一行 last_name 是 NULL，那 full_name 就是 NULL，不是“张三 ”或者别的什么，直接整个消失。MySQL 里用 CONCAT 也一样，CONCAT 遇 NULL 返回 NULL。

解决方式很简单，用 COALESCE 把可能为 NULL 的字段包成空字符串：

sql复制-- SQL Server
SELECT COALESCE(first_name + ' ' + last_name, '') AS full_name FROM users;

-- MySQL / PostgreSQL 写法
SELECT CONCAT(COALESCE(first_name, ''), ' ', COALESCE(last_name, '')) AS full_name FROM users;

这里有一个小技巧：对于 SQL Server，可以直接在拼接之后整体包一层 COALESCE，因为只要有一个字段是 NULL，结果就是 NULL，整体兜底能覆盖所有情况。但对于 MySQL 的 CONCAT，如果中间某个字段为 NULL，整体也会为 NULL，所以也要包。我更推荐的做法是每个字段单独包，虽然写起来长了一点，但谁为 NULL、谁不为 NULL，一眼就能看清。

2.4 聚合统计里的 SUM/AVG 与 NULL

聚合函数遇到 NULL 的规则比较隐蔽：SUM、AVG 这些函数会忽略 NULL 值，但如果这一组数据里的所有行该字段都是 NULL，函数的返回值就是 NULL，而不是 0。

举个例子，一张销售订单表，每一笔订单有一个 refund_amount 字段表示退款金额，没发生退款的订单这个字段是 NULL。你要统计整个月的退款总金额：

sql复制SELECT SUM(refund_amount) FROM orders WHERE order_date >= '2025-01-01';

这一个月只要有部分退款记录，那返回的就是这几个退款金额加起来，没问题。假如这个月一笔退款都没有，SUM 处理完全部 NULL 行之后，返回的就是 NULL，不是 0。很多报表工具遇到 NULL 就直接显示空白，或者前端代码把它显示成“NaN”，业务一看：这个月退款总额怎么是空？其实应该是 0。

这时候就要用 COALESCE 兜底：

sql复制SELECT COALESCE(SUM(refund_amount), 0) AS total_refund FROM orders WHERE order_date >= '2025-01-01';

AVG 也有类似的坑。比如说统计员工平均工资，有些员工的 salary 字段是 NULL（可能是实习生，工资还没录入），AVG 会直接忽略这些 NULL 行，只对有值的行求平均。如果你的业务口径是“全员平均，没录工资的按 0 算”，那就得先把 NULL 转成 0 再求平均：

sql复制SELECT AVG(COALESCE(salary, 0)) AS avg_salary FROM employees;

注意这个写法和 COALESCE(AVG(salary), 0) 完全不是一个意思。前者把每个 NULL 当 0 参与分母计算，后者只是兜底返回值，AVG 内部依然忽略 NULL。这就是聚合场景里最容易犯的口径错误，没有之一。

3. 进阶组合：COALESCE 和别的表达式怎么配合

3.1 NULLIF 搭档：除法防除零

COALESCE 最常见的搭档是 NULLIF。NULLIF 的作用正好相反：如果两个参数相等，返回 NULL；如果不相等，返回第一个参数。

sql复制NULLIF(expr1, expr2)

最经典的组合是除法计算，比如算环比增长率、占比、人均值，最怕除数为 0。SQL 里除以 0 要么报错，要么返回 NULL，不同数据库表现不一样。SQL Server 直接抛“遇到以零作除数错误”，MySQL 返回 NULL 但可能不符合业务要求。

你可以先用 NULLIF 把 0 转成 NULL，再用 COALESCE 把除法的结果兜底成 0。

sql复制SELECT
    sales_amount,
    user_count,
    COALESCE(sales_amount / NULLIF(user_count, 0), 0) AS per_user_amount
FROM daily_sales;

这个执行链路是这样的：user_count 如果是 0，NULLIF(user_count, 0) 返回 NULL，整个除法表达式变成 sales_amount / NULL，结果是 NULL，最后 COALESCE 把它转成 0。如果 user_count 不是 0，NULLIF 返回原本的 user_count，除法正常计算，COALESCE 不会干预。

还有一个小 trick：如果你想要结果是“除数为 0 时返回 NULL 而不是 0”，那就不需要外层的 COALESCE，直接 sales_amount / NULLIF(user_count, 0) 就可以。不过大多数业务场景里，报表宁可显示 0 也不想要 NULL，所以通常都要套一层。

3.2 CASE WHEN 的简洁替代

COALESCE 本质上就是“一连串 IS NULL 判断”的语法糖，和 CASE WHEN 有天然的等价关系。一个字段的兜底：

sql复制-- CASE WHEN 写法
CASE WHEN nickname IS NOT NULL THEN nickname ELSE '未设置' END

-- COALESCE 写法
COALESCE(nickname, '未设置')

多个字段的兜底：

sql复制-- CASE WHEN 写法
CASE
    WHEN phone IS NOT NULL THEN phone
    WHEN email IS NOT NULL THEN email
    ELSE account
END

-- COALESCE 写法
COALESCE(phone, email, account)

大多数人一看到这，立刻会觉得 COALESCE 更简洁，然后全面替换 CASE WHEN。但实际上两者并不完全等价，有个细节差异在于：CASE WHEN 是“先判断再取值”，如果 WHEN 条件不成立，它不会执行后面的表达式；而 COALESCE 在部分数据库里会先对所有参数做类型一致性推断，甚至可能先计算所有参数，这就可能带来副作用。

最典型的例子是 COALESCE(col, 1/0) 这类写法。在 SQL Server 里，COALESCE 为了保证类型一致性，可能提前评估 1/0，然后抛“遇到以零作除数错误”；而 CASE WHEN col IS NOT NULL THEN col ELSE 1/0 END 则不会，因为 CASE WHEN 是短路求值。这个问题我在 4.4 节还会再展开。简单结论是：常规的数据兜底场景，COALESCE 放心用；如果涉及到带有明显副作用或可能报错的表达式，就得警惕求值顺序问题。

3.3 UPDATE 里保留原值的更新逻辑

开发后管系统时，经常遇到“编辑用户资料”这种需求：前端只提交用户修改过的个别字段，未修改的字段不传或传 NULL。如果直接 UPDATE 全字段，NULL 就会把原值干掉。

用 COALESCE 可以优雅地解决这个问题：

sql复制UPDATE user_profile
SET
    nickname = COALESCE(:new_nickname, nickname),
    avatar = COALESCE(:new_avatar, avatar),
    intro = COALESCE(:new_intro, intro)
WHERE user_id = :user_id;

这里面的逻辑特别巧妙：如果传入参数是 NULL，COALESCE 会取回原字段值，等于什么都没改；如果传入新值，就更新为新值。这套逻辑在存储过程、后端服务层、甚至一条 SQL 里都能直接复用。

不过要提醒一句：这种写法要求“业务上不允许把字段改成 NULL”。如果你业务上确实支持“用户清空 nickname”，那 COALESCE 就不合适了，因为你没法把字段改成 NULL。我一般会在接口层先做一次请求参数校验，把“清空字段”和“未传字段”区分开，再决定走两条不同的更新逻辑。

3.4 行转列报表中填充 0

做数据透视表或者行转列报表时，缺失的组合在交叉表里会以 NULL 出现，这时候 COALESCE 可以顺手把 NULL 转成 0。举个简单的例子，按月份和支付方式统计订单数：

sql复制SELECT
    month,
    COALESCE(SUM(CASE WHEN pay_type = 'wechat' THEN 1 ELSE 0 END), 0) AS wechat_cnt,
    COALESCE(SUM(CASE WHEN pay_type = 'alipay' THEN 1 ELSE 0 END), 0) AS alipay_cnt,
    COALESCE(SUM(CASE WHEN pay_type = 'card' THEN 1 ELSE 0 END), 0) AS card_cnt
FROM orders
GROUP BY month;

这种写法在报表 SQL 里非常常见。加了 COALESCE 之后，即使某个月没有任何一笔支付记录，交叉表里对应单元格也是 0，而不是 NULL，前端做图表时就不用再写一堆“空值判断”的特殊逻辑。

4. 不同数据库下的行为差异与性能影响

4.1 SQL Server：ISNULL 和 COALESCE 的细节差异

SQL Server 同时提供 ISNULL 和 COALESCE，很多人以为它们一样，其实细节差异不少。

参数个数方面，ISNULL 只能接两个参数，COALESCE 可以接多个，这个前面已经说过。这里说两个容易踩坑的点。

第一个是返回类型的长度问题。ISNULL 返回值的类型取决于第一个参数的类型长度，而不是第二个参数。举个例子：

sql复制-- ISNULL 返回 VARCHAR(10)，'default value' 会被截断成 'default va'
SELECT ISNULL(CAST(NULL AS VARCHAR(10)), 'default value');

而 COALESCE 会按参数列表中“优先级最高”的类型来决定返回类型，如果后面字符串更长，它会更大程度地容纳。所以在 SQL Server 里，用 COALESCE 拼接较长字符串时，可能输出不截断，但用 ISNULL 会被截断。反过来说，如果你希望严格按某字段长度来处理，ISNULL 反而更可控。我自己遇到过一个线上事故就是 ISNULL 把长字符串截断了，项目日志里查不到任何错误，就是展示缺字，排查了大半天。

第二个是隐式转换的优先级。COALESCE 判断参数类型时，会按照数据类型的优先级做转换。如果你写：

sql复制SELECT COALESCE(CAST(NULL AS INT), 3.5);

在 SQL Server 里，INT 的优先级低于 numeric，所以返回值类型是 NUMERIC(2,1)，结果是 3.5。但如果反过来写：

sql复制SELECT COALESCE(CAST(NULL AS INT), 3.5);

在 SQL Server 里，INT 会被提升为 NUMERIC，结果也是 3.5，这不是问题。真正需要注意的是字符和数字混搭的情况，COALESCE(col_int, '未填写') 这种，SQL Server 可能会做隐式转换，把字符转成数字时直接报转换错误。遇到这种跨类型的兜底，最好先用 CAST 统一类型，比如 COALESCE(CAST(col_int AS VARCHAR(20)), '未填写')。

4.2 MySQL：IFNULL 和 COALESCE 的取舍

MySQL 里有两个函数都能做“非 NULL 返回第一个”，IFNULL 和 COALESCE。IFNULL 只有两个参数，COALESCE 可以多个。日常二选一的场景，两者等价，但 IFNULL 在语义上更“单薄”，只带两个参数，不能做多级回退。

MySQL 在处理 COALESCE 参数类型时，会根据表达式的优先级做隐式转换。如果你的整数字段和字符串常量混搭，MySQL 通常先把字符串转成数字再比较，这个行为可能导致你意料之外的结果。比如：

sql复制SELECT COALESCE(NULL, '12abc', 0);

MySQL 会尝试把 '12abc' 转成数字，结果是 12，于是查询返回 12，而不是你原本以为的 '12abc'。这种类型自动转换的坑在 MySQL 里非常隐蔽，因为 MySQL 对弱类型太宽容了，平时不报错，出了错还很难看出来。

所以我的建议是：MySQL 里使用 COALESCE，尽量保证参数列表中的类型一致，或者显式用 CAST 转换，不要依赖 MySQL 的隐式转换逻辑。

4.3 Oracle：NVL 的局限与 COALESCE 的长参列表

Oracle 里对应的是 NVL，只有两个参数。NVL 有个特点：它会强制要求两个参数类型一致，如果类型不一致，Oracle 会自动把第二个参数转换为第一个参数的类型。这就导致一个经典问题：

sql复制SELECT NVL(amount, '无') FROM orders;

amount 是 NUMBER 类型，'无' 是字符串，Oracle 会尝试把 '无' 转成 NUMBER，结果直接报“ORA-01722: invalid number”。如果换用 COALESCE：

sql复制SELECT COALESCE(amount, '无') FROM orders;

Oracle 也会报警告“ORA-01790: expression must have same datatype as corresponding expression”，同样是类型不匹配。所以在 Oracle 里遇到跨类型兜底，还是要靠显式 CAST 解决。

Oracle 的 COALESCE 最大优势是支持最多 255 个参数，这看起来有点夸张，但实际业务里不太可能用到这么多。另外，Oracle 的 COALESCE 文档里明确说，它不保证短路求值，也就是说，即使第一个参数已经非 NULL，后面的表达式也可能被计算。对有函数调用或可能抛错的表达式，要格外小心。

4.4 对索引的影响与常见的查询优化误区

很多人担心用了 COALESCE 之后索引失效。准确地说，不是“用了 COALESCE”导致索引失效，而是“对索引列做了函数运算”导致索引失效。比如：

sql复制SELECT * FROM users WHERE COALESCE(phone, '') = '13800138000';

这个查询里，phone 列被 COALESCE 包裹，数据库无法直接利用 phone 上的普通索引，只能全表扫描，因为要先算出 COALESCE 的结果才能跟常量比较。对比一下：

sql复制SELECT * FROM users WHERE phone IS NULL OR phone = '13800138000';

这种写法虽然看着笨，但对优化器友好得多，同样覆盖了 COALESCE 想表达的意图。

再强调一遍：COALESCE 用在 SELECT 的展示列、聚合兜底上，基本不影响性能；但如果出现在 WHERE 条件里，尤其是包裹了索引列，就要警惕了。部分数据库支持函数索引，MySQL 里可以建表达式索引，PostgreSQL 支持表达式索引，如果你确实需要按“COALESCE(col, 默认值)”去过滤，可以考虑建对应的函数索引。

最后补充一个容易被误解的点：COALESCE 本身不会随机屏蔽索引，优化器可能会根据你的条件做等价改写。比如 COALESCE(a, 1) > 5 这种查询，在 CBO（Cost-Based Optimizer）优化器下，部分数据库会自动改写成 a > 5 OR (a IS NULL AND 1 > 5)，后者恒假，实际就相当于 a > 5，这时候索引可能还能用上。但这些都属于数据库优化器的内部行为，不要过度依赖，最稳的做法还是避免在 WHERE 条件里用函数包字段。

5. 实战排查：报表统计对不上账，COALESCE 怎么救场的

5.1 问题现场：SUM 返回了 NULL

有一次我给某运营团队做月度销售报表，报表 SQL 大概长这样：

sql复制SELECT
    SUM(order_amount) AS total_amount,
    SUM(refund_amount) AS total_refund,
    COUNT(*) AS order_cnt
FROM orders
WHERE order_date BETWEEN '2025-01-01' AND '2025-01-31';

正常来说，总金额、总退款、订单数都会算出来。结果运营反馈：页面上的“总退款金额”是空的，其他两项都正常。我第一反应是数据有问题，就去数据库里直接跑这条 SQL，结果确实：total_refund 返回 NULL。

5.2 排查链路：从原始数据到临时方案

第一步，查原始数据：

sql复制SELECT refund_amount FROM orders WHERE order_date BETWEEN '2025-01-01' AND '2025-01-31';

结果这个月确实没有一笔退款，所有行的 refund_amount 都是 NULL。于是 SUM(NULL, NULL, ...) 的结果就是 NULL，不是 0。

第二步，临时方案，用 SQL Server 的 ISNULL 包一层：

sql复制SELECT ISNULL(SUM(refund_amount), 0) AS total_refund FROM orders;

这个 SQL 跑出来是 0，报表页面也正常了。本来以为事情到此结束，结果两周后又出问题了：运营导出的退款明细里，有一笔退款金额是 1234.56，但报表页面只显示了 1234。这是怎么回事？

第三步，发现问题根源。原来是这个报表 SQL 后来加了另一张表的 LEFT JOIN，ISNULL 的返回类型继承第一个参数的类型，SUM(refund_amount) 返回的类型是 NUMERIC(18,2)，按说不会截断。但问题出在 COALESCE 和 ISNULL 混用的时候，有人把原来的 ISNULL 改成了 COALESCE，然后 COALESCE 的类型判断跟另一个字符字段发生了隐式转换，最终展示时被截断了。

这个排查过程很折腾，最后我们把展示层的数据类型统一改成 NUMERIC(18,2)，并且对聚合结果一律用 COALESCE(SUM(column), 0) 这种写法，保持团队风格一致，不再混用 ISNULL 和 COALESCE。从那以后，这类“字段为空 / 小数被截断”的问题基本绝迹了。

5.3 收尾经验：写 SQL 时该有的“NULL 直觉”

经过那次排查，我建立了一个习惯：写任何查询之前，先在脑子里过一遍“哪些字段可能是 NULL”。不需要把每个字段都包一层 COALESCE，但遇到下面几类位置，基本必包：

LEFT JOIN 副表的字段，尤其是展示列。主表有记录，副表没有对应数据，副表字段就全是 NULL。
聚合函数的结果展示。SUM、AVG、MAX、MIN 在处理全 NULL 组时都可能返回 NULL。
前端有直接展示需求、且不允许显示空白的字段，比如金额、比率、状态文案。

另外再分享一个小的经验：很多团队会规范要求 SELECT 里的字段在返回给上层前统一做 COALESCE 兜底，但千万别做过头。如果一个字段可能为 NULL 且业务上 NULL 是有意义的（比如“根本没有数据”和“数据为 0”是两种含义），就不该用 COALESCE 强行抹掉区别。先想清楚业务口径，再决定要不要兜底。我见过有人把 COALESCE 当万能膏药，哪里 NULL 贴哪里，最后把“用户确实没填写手机号”和“手机号数据缺失”混在一起，统计报表直接失真，这种锅可比页面显示 NULL 严重多了。