isnull 替代 coalesce 几乎不提升性能，反而易引发类型错误、隐式转换或兼容性问题；二者执行差异在纳秒级，对查询无实际影响。
别用 ISNULL 替代 COALESCE 来“提升性能”——在 SQL Server 中，这种替代几乎从不带来可测量的性能收益，反而大概率引入类型错误、隐式转换或跨库兼容性问题。
ISNULL 在 SQL Server 中确实比 COALESCE 略快，但差距可以忽略
执行计划层面，ISNULL 是一个内联标量函数，而 COALESCE 在 SQL Server 内部会被重写为 CASE 表达式（例如 COALESCE(a, b) → CASE WHEN a IS NOT NULL THEN a ELSE b END）。这多一层解析和生成逻辑，理论上略重。
但实测中： - 单次调用差异在纳秒级，对整条查询无影响 - 即使在百万行结果集上批量使用，CPU 时间差通常
ISNULL 的类型行为是最大陷阱，不是优化点
ISNULL 强制返回第一个参数的类型，且会静默截断或转换第二个参数：
-
ISNULL(CAST(NULL AS VARCHAR(2)), 'hello')→ 返回VARCHAR(2)，结果是he（被截断） -
ISNULL(CAST(NULL AS INT), '123')→ 成功，但'123'被转成INT；若写成'abc'则直接报错Conversion failed -
COALESCE(CAST(NULL AS INT), '123')→ 报错，因为字符串不能隐式转为INT（按数据类型优先级规则）
这意味着：用 ISNULL “替换” COALESCE 时，你很可能在不知情下破坏了数据精度、长度或引发运行时报错——这不是性能优化，是埋雷。
真正该关注的性能点：WHERE 和 JOIN 中的 NULL 处理
函数本身快慢无关紧要；真正拖慢查询的是对 NULL 的错误判断方式：
-
WHERE col = NULL永远不匹配，优化器无法走索引 → 必须改用WHERE col IS NULL -
WHERE ISNULL(col, 0) = 0或WHERE COALESCE(col, 0) = 0都会让col上的索引失效（函数包裹列） -
LEFT JOIN t2 ON t1.id = t2.ref_id中，若t2.ref_id含 NULL，不会匹配任何行 —— 这是语义问题，不是函数问题
想提速？优先检查：IS NULL 是否被正确使用、是否在 WHERE 中对列直接运算、统计信息是否更新、执行计划里有没有意外的表扫描。
跨数据库迁移时，COALESCE 是唯一安全选项
如果你的代码未来可能跑在 PostgreSQL、MySQL 或 Oracle 上：
-
ISNULL在这些系统中根本不存在（PostgreSQL 有同名但语义不同；MySQL 完全不识别） -
COALESCE是 ANSI SQL 标准，所有主流数据库都支持且行为一致 - 哪怕现在只用 SQL Server，硬切
ISNULL也会让后续迁移成本陡增
所谓“性能提升”在这里毫无意义：一次迁移失败带来的停机和重写成本，远超十年里所有 COALESCE 多花的那几微秒。
最常被忽略的一点：当你在纠结 ISNULL vs COALESCE 时，真正该检查的是——这个字段为什么会有大量 NULL？业务建模是否合理？默认值能不能前置到应用层或 DEFAULT 约束里？函数只是补救，不是设计。
