企业官网建设流程全解析

做SQL Server开发的人都清楚，SELECT、JOIN、GROUP BY这些语法刚接触时觉得难，真正用了两三年的老手反而不会在它们身上翻车——大家最常栽跟头的，其实是NULL。NULL不是0，也不是空字符串，它表示“未知”“还没填”“根本不适用”。一张用户表里，手机号可能没录，生日可能没录，备注更是十行里有八行是NULL。于是查询结果里到处是空白，报表里一排“无”，程序里各种空引用异常。COALESCE就是专门收拾这种局面的函数，它干的事情很纯粹：给你一串表达式，从左往右找第一个不是NULL的值返回。这章笔记我把COALESCE从语法到实战、从性能陷阱到版本差异一次讲透，新手照着抄就能用，老手也可以对照检查一下自己有没有踩过那些隐蔽的坑。

1. 从NULL说起：COALESCE的定位与基本语法

1.1 数据库里NULL到底意味着什么

要理解COALESCE，得先理解NULL为什么让人头疼。SQL是集合操作语言，而NULL是“三值逻辑”的产物：一个比较结果不只是TRUE和FALSE，还有UNKNOWN。举例来说，WHERE age > 18，如果age是NULL，这一行的判断结果是UNKNOWN，最终会被过滤掉。NULL参与算术运算也很有意思：salary * 1.1，只要salary是NULL，结果就是NULL——这很符合直觉，你不知道底薪是多少，自然算不出涨薪后的数。

真正的麻烦在于业务层面。用户注册时没填手机号，系统存了NULL；过两天他补填了，你更新成13800138000。看起来很简单，但你要是无脑拿phone = '13800138000'去查，永远查不到那条以前是NULL、现在是手机号的记录——这是另一个话题，涉及WHERE条件怎么写。而如果查询结果要把这些NULL展示成“未填写”，或者要优先取一个可用的联系方式，你就需要COALESCE这种“兜底”函数。可以这么理解：COALESCE是给数据穿了一层保险，那一串参数里谁先有值，就先用谁。

1.2 COALESCE的基本语法与求值规则

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

COALESCE(expression1, expression2, ..., expressionN)

它做的事是：按从左到右的顺序检查每个表达式，返回第一个计算结果不为NULL的表达式。如果所有表达式都是NULL，那么COALESCE返回NULL。

几个细节要敲黑板：

• 参数数量没有硬性限制，但实践中一般两到三个就够用了，参数越多，可读性越差。
• 每个表达式都会被“求值”，至于这个求值是快是慢，后面章节单独说——这里先记住一个概念：SQL Server对COALESCE的处理，真的会把参数都算一遍。
• 结果的类型不是随便定的，它遵循“类型优先级”规则，取参数列表中优先级最高的类型。

看个最基础的例子，假设有一个销售订单表，订单有预计交货日期expected_date，也有实际交货日期actual_date，查询时希望优先显示实际日期，没有实际日期就用预计日期：

SELECT order_id, COALESCE(actual_date, expected_date) AS display_date FROM sales_orders;

这是COALESCE最常见的形态：两个参数，一个业务字段，一个兜底字段。很多人第一次接触这个函数就是从这里开始的。后面你会发现，它还能玩出更多花样。

1.3 返回类型是如何确定的

这一点非常容易被忽略，但它是很多类型转换报错的根源。SQL Server内部有一个数据类型优先级列表，从最高到最低大致是：datetime、smalldatetime、float、money、decimal、int、bigint、varchar、char、nvarchar……COALESCE返回类型取这些参数中优先级最高的那个。

举例：

SELECT COALESCE(phone_no, '未知'); -- phone_no是varchar，'未知'也是varchar，返回varchar SELECT COALESCE(quantity, 0); -- quantity是int，0是int，返回int SELECT COALESCE(price, 0); -- price是decimal(18,2)，0是int，返回decimal(18,2)

前两个没什么问题，第三个就要小心了：int会隐式转换成decimal，没问题。但如果你写成COALESCE(price, '免费')，price是decimal，'免费'是varchar，按照优先级，decimal更高，SQL Server会尝试把'免费'这个字符串转成decimal，然后当场报错：Error converting data type varchar to numeric。

这里要形成条件反射：COALESCE的参数，必须保证能互相隐式转换，而且转换方向是“向类型优先级高的方向转”。不是你想当然地以为“哪个是字符串，就把哪个显示出来”。

2. COALESCE与ISNULL：选了这么多年，终于把差异讲清楚

2.1 参数数量不同

很多人会问：SQL Server里不是早就有一个ISNULL函数吗？ISNULL(check_expression, replacement_value)，同样是第一个参数为NULL就换成第二个参数，那COALESCE是不是多此一举？

参数数量是最直观的区别。ISNULL只能传两个参数，一个检查表达式，一个替换值。COALESCE可以传多个。比如你要依次取“手机号→家里电话→公司电话→'无联系方式'”，ISNULL要写成三层嵌套：

-- ISNULL嵌套写法 SELECT ISNULL(ISNULL(ISNULL(mobile, home_phone), office_phone), '无联系方式') FROM customers; -- COALESCE写法 SELECT COALESCE(mobile, home_phone, office_phone, '无联系方式') FROM customers;

嵌套多了不光写着累，而且很容易漏括号。COALESCE这个多参数的特性，在处理多字段优先级取值时几乎是为它量身定做的。

2.2 类型处理机制不同

参数数量只是表面，真正影响你选型的是类型处理机制。ISNULL的类型是以第一个参数为准的，它不会做“跨类型推断”。举个例子：

SELECT ISNULL(price, 0); -- price是varchar，0是int，结果类型是varchar，'0'被转成字符串 SELECT COALESCE(price, 0); -- price是varchar，0是int，int优先级高，结果类型是int，price必须能转int

这个差异在实际业务中影响巨大。如果你的price列是varchar（我知道，设计不规范，但老系统里到处都是），里面存着一些非数字的内容比如“面议”，ISNULL(price, 0)能正常返回“面议”或“0”，但COALESCE(price, 0)会直接报转换错误，因为它要把整个列转成int再决定返回什么。

另一个差异在日期时间类型上：ISNULL第一个参数是datetime，那么第二个参数如果是字符串'2024-01-01'，会被当作datetime处理，结果是datetime类型；COALESCE则是两个参数里datetime优先级更高，字符串会被隐式转成datetime，结果也是datetime。表面看差不多，但一旦字符串格式有问题，COALESCE报错，ISNULL反而可能因为直接“当作字符串原样返回”而逃过一劫——不对，ISNULL其实也会做转换，差别在于它对第二个参数的转换是按第一个参数的类型来的，同样可能报错，只是报错时机和参数顺序的影响不同。

2.3 ANSI兼容与团队协作：为什么默认推荐COALESCE

从标准层面看，COALESCE是ANSI SQL标准里的函数，ISNULL是SQL Server私有的。这意味着你的SQL如果要在MySQL、PostgreSQL、Oracle之间迁移，COALESCE可以直接带过去，而ISNULL到MySQL里语义完全不一样（MySQL的ISNULL只返回0或1，是个判断函数），到Oracle里压根没有ISNULL，只有NVL。

这点在小团队里无所谓，大家统一用SQL Server，写ISNULL也没毛病。但如果你在金融、电商这类系统里，哪天业务要换数据库，或者要做跨库数据同步、ETL脚本复用，COALESCE的移植成本低得多。我在项目里定过一个不成文规矩：写新代码一律用COALESCE，ISNULL只允许在“改造存量脚本时顺手保留”和“明确知道类型要以第一个参数为准”的场景下使用。统一标准的好处是code review时不用每次纠结这个人为什么用ISNULL、那个人为什么用COALESCE。

2.4 什么场景下ISNULL反而更合适

如果COALESCE这么好，为什么还要保留ISNULL？因为它快，或者说在某些场景下它的行为更符合你的预期。

第一个场景是“不想让类型推断牵着你走”。假设你有一个存储过程的参数@status，类型是varchar(10)，你想实现“如果传入参数为NULL，则不过滤状态”：

WHERE status = ISNULL(@status, status)

这个写法在SQL Server里成立，因为ISNULL第二个参数status会被转成@status的类型，两边可比。但如果用COALESCE就要小心，一旦status列类型和@status不同，类型推断可能改变结果的类型，轻则隐式转换导致索引失效，重则直接报错。

第二个场景是“单参数替换且需要严格保持第一个参数类型”。ISNULL的返回类型永远跟随第一个参数，这让它在一些计算列、派生表中非常稳。比如：

ALTER TABLE dbo.orders ADD discount_amount AS ISNULL(discount, 0);

你希望discount_amount的类型和discount列完全一致，用ISNULL保证不会因第二个参数是int而把类型抬升。用COALESCE的话，如果discount是decimal(10,2)、0是int，结果还是decimal(10,2)，不算坏，但传参时类型状态的确定性不如ISNULL。说白了，ISNULL像是一个保守派，COALESCE像一个自由派，选谁取决于你是否需要“类型完全可控”。

3. 五个高频实战场景：从查询展示到报表处理

3.1 场景一：字段默认值兜底

最基础的用法，给可空字段配一个展示用的默认值。比如客户表里备注字段remark，大部分行是NULL，导出数据时希望显示成“无备注”：

SELECT customer_id, COALESCE(remark, '无备注') AS remark_display FROM customers;

这里有一个常见误解：有人以为COALESCE能顺手处理空字符串。注意，空字符串''不是NULL，COALESCE看到''会认为“这个值有效”，直接返回''。所以如果你希望“空字符串也显示成无备注”，得先处理一下空串：

SELECT customer_id, COALESCE(NULLIF(remark, ''), '无备注') AS remark_display FROM customers;

NULLIF的用法是：两个参数相等就返回NULL，这里NULLIF(remark, '')就把空字符串变成NULL，外层的COALESCE再兜底成“无备注”。这种NULLIF和COALESCE的搭配在SQL里非常经典，后面还会见到。

3.2 场景二：多字段优先级取值

这是COALESCE最能体现价值的地方。业务上经常有“多个联系方式，取第一个有效的”这种需求。比如用户表存了手机、座机、紧急联系人电话，排序规则是手机优先、座机次之、紧急联系人最后：

SELECT user_id, COALESCE(mobile_phone, landline, emergency_phone, '无') AS primary_contact FROM users;

写一个JAVA或者C#程序，你得先判断手机号是否为空，再判断座机是否为空，至少三五个if。SQL里一个COALESCE就搞定，而且查询计划是相对固定的，代码也更好维护。类似的场景还有地址拼接：省份、城市、区县都可能为空，你可以按省级、市级逐级兜底，也可以后续拼接时统一处理。唯一要提醒的是，COALESCE只是“返回第一个非NULL”，它不会帮你判断空字符串。如果某个手机号字段被应用层写成了空字符串而不是NULL，这个函数会直接返回''，排名靠后的座机号码反而没机会上场。这种跟数据类型无关、跟数据质量有关的问题，靠函数解决不了，得从写入端想办法。

3.3 场景三：字符串拼接与老版本兼容

报表里经常要把几个字段拼成一句话，比如“XX省XX市XX区”。最简单直接的想法是：

SELECT province + city + district FROM address_table;

但只要其中任何一个字段是NULL，整个表达式的结果就是NULL——SQL Server对字符串连接里的NULL就是这么严格。当年我入职第一周就遇到过这个问题，拼接地址出现大量NULL行，排查半天发现是district为空。

解决办法就是给每个字段都套COALESCE：

SELECT COALESCE(province, '') + COALESCE(city, '') + COALESCE(district, '') AS full_address FROM address_table;

这里有个版本相关的细节要提醒：SQL Server 2012开始提供了CONCAT函数，CONCAT(province, city, district)会自动把NULL当作空字符串处理，不需要手动包COALESCE。但如果你的服务器还是2008 R2或者2012以下版本，或者你写的SQL要兼容多个版本，CONCAT用不了，老老实实用COALESCE是唯一选择。另外，CONCAT的隐式空串处理也带来一个小坑：如果三个字段全是NULL，CONCAT返回的是空字符串而不是NULL，这在某些需要区分“地址不存在”和“地址为空”的业务里是个坑，COALESCE方案则可以按需把整个拼接结果再兜底成'地址未知'：

SELECT COALESCE( COALESCE(province, '') + COALESCE(city, '') + COALESCE(district, ''), '地址未知' ) AS full_address FROM address_table;

3.4 场景四：聚合结果空值处理

分组聚合之后，经常出现某些组没有记录的情况。比如按月统计销售额，2月没有订单，那么SUM(amount)的结果不是0，而是NULL。报表工具碰到NULL会显示空白，前端拿到NULL还可能直接罢工。处理方式就是在聚合结果外面套COALESCE：

SELECT month_no, COALESCE(SUM(amount), 0) AS total_amount FROM sales GROUP BY month_no;

同样的套路在PIVOT透视表里更常见。把行转列之后，那些没有数据的交叉单元格全是NULL，如果报表层不想看到NULL，就得在透视结果外统一替换。注意，这种情况下替换成0还是替换成“-”，取决于业务含义。销售额缺失是“没有卖出去”，用0合理；但客户性别缺失是你根本没采集这个维度，用“未采集”比用0更诚实。COALESCE不关心你的业务语义，它只是个工具，用得好不好取决于你往里塞什么。

3.5 场景五：日期范围与截止日期推算

COALESCE处理日期也很顺手。比如合同的结束日期end_date可以为空，为空时表示长期有效。你要算“合同当前是否有效”，就可以用COALESCE把NULL截止日期当作一个很远的日期：

SELECT contract_id, CASE WHEN COALESCE(end_date, '9999-12-31') >= GETDATE() THEN '有效' ELSE '已失效' END AS contract_status FROM contracts;

这类写法在会员到期、订阅续费、优惠券有效期等场景遍地都是。还有一种是取两个日期中“更晚生效”的：

SELECT order_id, COALESCE(actual_ship_date, expected_ship_date) AS ship_date FROM orders;

注意，这里是“取第一个可用的日期”，不是“取更晚的日期”。如果业务是要取更晚的那个，得用CASE WHEN或MAX，不能拿COALESCE硬套。函数的大原则是：先用对，再求妙。

4. 踩坑实录：COALESCE的三个经典雷区

4.1 雷区一：类型转换报错

开头提到过的那句热搜词“sql server conversion failed when converting date and/or time from character string”，正是COALESCE类型推断引发的经典报错。我见过一个真实案例。存储过程里有一个@start_date参数，按varchar传入，查询里这样写：

WHERE create_date >= COALESCE(@start_date, '1900-01-01')

create_date是datetime类型，字符串'1900-01-01'在比较时会尝试转成datetime，这个没问题。但坑的是，@start_date如果传入了'2024-13-45'这种无法解析的字符串，COALESCE在比较阶段做隐式转换时就会抛“conversion failed when converting date and/or time from character string”。问题本事不在COALESCE，而在于你让一个varchar参数直接和datetime列比较时没有显式转换。解决方案是，参数类型直接定义为datetime，或者在传入前就用TRY_CONVERT或TRY_PARSE做校验：

WHERE create_date >= COALESCE(TRY_CONVERT(datetime, @start_date), '1900-01-01')

再举一个容易中招的类型组合：varchar列和int常量做COALESCE。前面说过，int优先级高于varchar，导致varchar列的所有值都要先转成int才能参与COALESCE计算，一旦列里有'abc'、'未填写'这类脏数据，整个查询直接报错。解决办法要么把列先转成varchar，要么干脆别让两种类型混在一个COALESCE里：

-- 安全写法：先统一成字符串 COALESCE(CAST(quantity AS varchar(20)), '未知数量')

4.2 雷区二：COALESCE会评估所有参数

这是很多人的知识盲区。直觉上，COALESCE从左往右找，找到第一个非NULL就停，应该像短路求值一样，后面的参数就不算了。但SQL Server的查询引擎不是这样实现的。在大多数情况下，COALESCE会评估所有参数，然后才选择返回哪个。

这意味着什么呢？如果你写了类似这样的语句：

SELECT COALESCE( (SELECT TOP 1 name FROM dim_product WHERE product_id = o.product_id), (SELECT TOP 1 name FROM dim_product_old WHERE product_id = o.product_id), '未匹配' ) FROM orders o;

你以为第一个子查询有结果时，第二个子查询不会执行。但实际上，SQL Server可能把两个子查询都执行一遍。如果两个子查询背后都是大表、大索引，性能就是双倍的。

这里有一个容易被误解的点：不是说COALESCE“绝对”会执行所有参数，而是它的执行计划不具备CASE表达式那种稳定的短路语义。SQL Server优化器有时会重写COALESCE为CASE，有时不会，有时部分重写。你不能依赖它的短路行为。如果业务上确实需要严格控制“只执行第一个有效分支”，那就写CASE表达式：

SELECT CASE WHEN o.product_id IS NOT NULL THEN (SELECT TOP 1 name FROM dim_product WHERE product_id = o.product_id) WHEN o.product_id IS NOT NULL THEN (SELECT TOP 1 name FROM dim_product_old WHERE product_id = o.product_id) ELSE '未匹配' END FROM orders o;

虽然CASE也不能保证每条子查询一定被短路执行，但优化器对CASE的“条件过滤”语义更明确，配合索引和统计信息，有点希望能做得更好。反正在性能敏感的地方，不要指望COALESCE帮你省子查询的执行，该用CASE的用CASE。

4.3 雷区三：空字符串是空字符串，NULL是NULL

这个坑可以单独开一篇，但在这里必须强调。COALESCE只认NULL，不认空字符串、不认0、不认'false'。比如配置表里有个默认库存阈值threshold，有些行存了0，有些行存了NULL。COALESCE(threshold, 10)返回0还是10？答案是0。0是合法值，不是NULL，COALESCE原样返回。

同样，用COALESCE做“空串兜底”时会失效：

SELECT COALESCE(remark, '无备注') FROM customers; -- remark = '' 时，返回 ''，不是 '无备注'

这跟业务的数据标准有关。有的系统习惯“未填写的字符串存NULL”，有的系统习惯“存空字符串”，还有的系统垃圾数据里两种都有。COALESCE拿这种混合数据没辙，你必须先用NULLIF把空串转成NULL，才能让COALESCE接管。所以很多成熟SQL开发者的代码里，出现频率最高的组合其实是COALESCE(NULLIF(...), ...)，既有兜底又处理了空串。

4.4 雷区四：查询条件中用了COALESCE导致索引失效

这也是个实战高频问题。经常有人为了让查询条件里的NULL值也能命中，写出这种语句：

SELECT * FROM orders WHERE COALESCE(status, '') = 'PENDING';

这样写语法没问题，但status列上的索引基本废了。函数套在列上，除非是计算列且建了索引，否则SQL Server没办法直接走索引，只能扫描。我见过一张百万行订单表，因为这种写法执行时间从几十毫秒涨到好几秒。

正确写法是把条件拆开，显示处理NULL：

SELECT * FROM orders WHERE status = 'PENDING' OR status IS NULL;

如果NULL表示“待处理”，那这个OR条件可以命中索引吗？status = 'PENDING'可以走索引，但OR加上status IS NULL后，查询计划常常变成合并或扫描。更优的做法是索引里加过滤条件，或者直接用WHERE status IS NULL单独查询，把两种状态的记录分开处理。这个问题的本质不是COALESCE本身慢，而是你对列使用了函数，破坏了索引可用的前提。排查性能问题时看到执行计划里出现Index Scan、而WHERE里又有COALESCE，第一反应先把它改成OR条件试试。

5. 进阶玩法：COALESCE在存储过程、UPDATE与约束中的技巧

5.1 存储过程参数兜底

存储过程经常遇到“参数可传可不传，不传就用默认值”的需求。默认的写法是：

CREATE PROCEDURE dbo.GetUsers @keyword VARCHAR(50) = NULL AS BEGIN SET @keyword = COALESCE(@keyword, ''); SELECT * FROM users WHERE name LIKE '%' + @keyword + '%'; END

这里COALESCE的用处是让后面所有逻辑都基于一个已经非NULL的变量，避免到处写@keyword IS NOT NULL的判断。类似的，计算分页偏移量时，如果某参数允许NULL代表“不限制”，可以先兜底成0或一个大值。

还有一种更高级的用法是配合默认值实现“按需覆盖”。比如一个更新资料的存储过程，允许只传入部分字段，其他字段保持原值：

UPDATE users SET nickname = COALESCE(@new_nickname, nickname), avatar = COALESCE(@new_avatar, avatar) WHERE user_id = @user_id;

这个写法的妙处在于：传入NULL就保持原值，传入非NULL就覆盖。不用事先判断哪个参数是NULL，SQL本身就把逻辑说清楚了。但要注意，它有个固有缺陷：如果你想真的把某个字段更新为NULL，这个写法做不到——COALESCE会把NULL当成“不更新”，而不是“更新为NULL”。需要清空字段的业务，得单独处理。

5.2 用COALESCE做增量维护和历史快照

还有一类场景经常被忽略：COALESCE在小计、累计、差异对比中也有妙用。比如我们要维护每个月的订单累计金额，月初的累计值AMOUNT是NULL，然后每次进来一笔新订单，就执行：

UPDATE monthly_summary SET total_amount = COALESCE(total_amount, 0) + @new_amount WHERE month_no = @month;

这比先SELECT再判断NULL再UPDATE要优雅得多，一条语句搞定，也避免了并发下读到旧值的问题。当然，更严谨的并发控制需要配合事务和锁，但至少在“避免NULL累加变成NULL”这个层面，COALESCE是称职的。

在多表关联求差异时也常见：左连接后，右表没有匹配上，右表字段全是NULL。你想算“目标值减去已完成的差值”，可以用：

SELECT a.task_id, a.target_value - COALESCE(b.finished_value, 0) AS remaining FROM tasks a LEFT JOIN task_progress b ON a.task_id = b.task_id;

如果不用COALESCE，任何没进度的任务remaining都会是NULL，根本算不出来。这种场景里COALESCE就是给LEFT JOIN的NULL擦屁股的，擦完才能做算术。

5.3 计算列与CHECK约束中的应用

计算列上也能用COALESCE。比如表里有首付金额down_payment和尾款final_payment，允许其中一个为空（比如全款付清时尾款为空），但希望计算列always存一个“应付总额”：

ALTER TABLE payments ADD total_amount AS COALESCE(down_payment, 0) + COALESCE(final_payment, 0);

只要源列更新，这个计算列自动更新，查询时直接当普通列用，还能在上面建索引。注意建索引的话，计算列必须是确定性的，COALESCE是确定性函数，满足要求。

CHECK约束里也能用。比如要求“发货日期不能早于下单日期时，如果发货日期为空则忽略”：

ALTER TABLE orders ADD CONSTRAINT chk_ship_date CHECK (COALESCE(ship_date, order_date) >= order_date);

ship_date为NULL时，COALESCE返回order_date，比较结果order_date >= order_date成立；ship_date有值时，比较实际日期。这样既约束了数据，又不影响“还没发货”的合法记录。这种写法尤其适合那些“可空字段但一旦有值必须满足某规则”的业务场景。

5.4 COALESCE + NULLIF 组合：优雅解决除零问题

报表里算占比、算增长率时，除零问题几乎躲不掉。SQL Server里除以0会直接报错“Divide by zero error encountered”，但可以先用NULLIF把0变成NULL，再用COALESCE把NULL变成0或跳过：

SELECT category_id, COALESCE(sales_amount / NULLIF(prev_amount, 0), 0) AS growth_ratio FROM sales_report;

这里NULLIF(prev_amount, 0)的作用是：prev_amount为0时返回NULL，除以NULL结果还是NULL，外层COALESCE把NULL兜底成0，安全返回。还有一个变体是把除零结果左接成NULL让前端自己展示：

SELECT category_id, sales_amount / NULLIF(prev_amount, 0) AS growth_ratio FROM sales_report;

前端拿到NULL显示“-”，业务语义是“无法计算”，比显示0更准确。COALESCE和NULLIF这两个函数一个管“兜底”，一个管“标记特殊值”，搭配起来能解决很多边界问题。

6. 问题排查速查表与实际经验补充

6.1 常见问题速查表

6.2 排查经验：如何快速定位COALESCE相关报错

当查询报错信息里带着“conversion failed”字样，而你怀疑跟COALESCE有关时，我建议按下面顺序排查：

先看错误信息里的对象类型。SQL Server一般会告诉你“conversion failed when converting the varchar value 'xxxx' to data type int”或“from character string”，这能直接定位是哪个值出了幺蛾子。然后看COALESCE参数列表里有没有混进不同类型。最常见的组合是varchar列和数字常量，或者varchar参数和datetime列。最后验证方法很简单，把COALESCE改写成一个子查询，或者临时把可疑参数CAST成统一类型试运行。

另外，在调试存储过程时，可以用TRY_CONVERT包一层，这样即使转换失败也只会返回NULL，不会直接炸掉。这个策略适合“宁可显示未知，也不能让整个查询崩溃”的场景：

COALESCE(TRY_CONVERT(datetime, @input), GETDATE())

6.3 性能经验：COALESCE什么时候必须小心

性能问题主要出现在三处。第一处前面说过了，WHERE条件里对列做COALESCE，破坏索引。第二处是COALESCE参数里有子查询或标量函数，它可能全部评估，导致不必要的I/O。第三处是COALESCE返回类型是varchar时，字符串长度可能因隐式转换被截断或变长，影响内存和排序。

我习惯的做法是：能用常量当最后一个参数，就不要放子查询；能用简单列当参数，就不要放函数套函数。如果COALESCE用于SELECT输出层，性能影响通常可接受；一旦进入JOIN ON条件、WHERE过滤或ORDER BY排序，就要警惕——它可能迫使优化器做更多计算。

还有一个小技巧：如果你需要在一个大查询里多次用同一个COALESCE结果，尽量不要到处重复写这个函数，而是用子查询或CROSS APPLY先算一次，再引用。比如：

SELECT t.order_id, t.display_date FROM ( SELECT order_id, COALESCE(actual_date, expected_date, '9999-12-31') AS display_date FROM orders ) t WHERE t.display_date < GETDATE();

这样既保证了逻辑统一，又避免优化器在多个地方重复计算同一个表达式。当然，SQL Server的表达式合并有时会自动做，但这种显式写法更可控，也更好维护。

我个人做了这么多年SQL Server，对NULL的态度从“烦透了”变成了“尊重”：NULL是数据的一部分，不处理好它，查询结果就是薛定谔的猫——你以为有值，实际没有。COALESCE解决的是“如何展示一个非NULL结果”的问题，但它不解决“NULL是否应该存在”的问题，后者要靠表设计、约束和应用层写入规范去控制。如果你还在用ISNULL顺手写新代码，我建议下次试着改成COALESCE，跑一段时间你会发现代码在往ANSI标准靠拢，跨库迁移时也会少吃点亏。最后分享一个小习惯：每写完一个带COALESCE的查询，我都会刻意检查一遍所有参数的类型是否能互相转换、最后一个参数是否是常量。这个检查十秒钟就能做完，但能省下的排查时间，往往是以小时计的。