COALESCE执行计划常比等价CASE WHEN更干净，因其语义明确、结构简单，优化器有专用识别路径，支持短路且内联为单节点；但在WHERE或ORDER BY中易破坏索引，导致全表扫描。
COALESCE 本身不保证执行计划更优，但它的语义明确、结构简单，在多数场景下更容易被优化器识别为“空值兜底”模式，从而避免生成冗余分支逻辑。 它不是性能银弹，但比手写等价的 CASE WHEN 更少引入人为干扰项。
COALESCE 的执行计划为什么常比等价 CASE WHEN 更干净？
数据库优化器对 COALESCE 有专用识别路径，而对 CASE WHEN 需要逐层解析条件表达式。尤其当嵌套多层或混用函数时，CASE WHEN 容易触发额外的表达式重写或临时列生成。
-
COALESCE(a, b, c)在 PostgreSQL 和 SQL Server 中通常被内联为单个“first-non-null”节点，执行计划里只出现一次列扫描 - 等价的
CASE WHEN a IS NOT NULL THEN a WHEN b IS NOT NULL THEN b ELSE c END可能被展开为多个IS NOT NULL判断，部分引擎（如旧版 MySQL）会为每个WHEN分支生成独立的谓词评估步骤 - 如果
a、b是计算列或子查询，CASE WHEN无法保证短路——某些优化器会在编译期就决定全部求值；而COALESCE明确要求短路，主流数据库（PostgreSQL 15+、SQL Server 2022、MySQL 8.0.30+）均严格遵守
什么时候 COALESCE 反而让执行计划变差？
不是所有 COALESCE 都安全。它在过滤和排序上下文中极易破坏索引利用，此时执行计划劣化是常态。
-
WHERE COALESCE(status, 'active') = 'active'：几乎所有数据库都会放弃status上的索引，改走全表扫描 -
ORDER BY COALESCE(updated_at, created_at)：除非你显式建了函数索引（如CREATE INDEX idx_fallback ON tbl ((COALESCE(updated_at, created_at)))），否则会强制排序临时结果集 - 参数类型不一致导致隐式转换：例如
COALESCE(int_col, 'N/A')在 PostgreSQL 中直接报错，在 MySQL 严格模式下也会触发类型推导失败，最终退化为全表扫描+逐行 cast
COALESCE 和 CASE WHEN 的性能差异到底看什么？
真正影响执行计划的是「是否可索引」「是否触发隐式转换」「是否引入不可预测的副作用」，而不是函数名本身。
- 在
SELECT列中：两者生成的执行计划通常一致，COALESCE因语法简洁，反而更少出错 - 在
WHERE子句中：优先拆解为col = val OR col IS NULL，而非依赖COALESCE或CASE WHEN - 涉及聚合前处理：如
SUM(COALESCE(discount, 0))比SUM(CASE WHEN discount IS NOT NULL THEN discount ELSE 0 END)更易被向量化执行引擎识别为纯标量替换 - 跨库迁移时：
COALESCE行为统一，而不同数据库对CASE WHEN中空字符串、零值、NULL 的比较逻辑可能有细微差异，导致执行计划在目标库中意外改变
别迷信“函数名=性能好”。COALESCE 的优势在于它把“取第一个非 NULL”这个意图锁死了，减少了优化器猜错的可能性；但一旦你把它用在不该用的地方（比如 WHERE 或 ORDER BY），再标准的函数也救不了执行计划。
