coalesce是sql标准函数，统一返回第一个非null值，但postgresql/sql server严格校验参数类型兼容性，mysql支持隐式转换；跨库应显式类型转换如coalesce(cast(col as text), 'n/a')。
COALESCE 函数在不同数据库中的行为差异
COALESCE 是 SQL 标准函数，但各数据库对它的空值判断逻辑一致：从左到右返回第一个非 NULL 的表达式值。不过要注意，PostgreSQL 和 SQL Server 会严格检查所有参数类型是否兼容，而 MySQL 宽松些，会尝试隐式转换。
常见踩坑点：COALESCE(col, '') 在 PostgreSQL 中若 col 是 INT 类型，就会报错“cannot cast type integer to text”，必须显式转换：COALESCE(col::text, '')。
使用建议：
- 优先用
COALESCE，它跨数据库兼容性好（SQLite、PostgreSQL、SQL Server、Oracle 都支持） - 避免混用不同类型，尤其在强类型数据库中；不确定时统一转成文本：
COALESCE(CAST(col AS TEXT), 'N/A') - 参数数量不限，但顺序很重要——把最可能非空的字段放左边，提升执行效率
MySQL 专用 IFNULL 函数的局限性
IFNULL 只接受两个参数，且仅在 MySQL 和 MariaDB 中可用。它比 COALESCE 简单直接：IFNULL(col, 'default')，但无法应对多层 fallback 场景（比如先试 A，不行再试 B，最后才是默认值）。
典型错误现象：IFNULL(col1, col2, 'fallback') 会直接报错 “Incorrect parameter count”，因为语法不合法。
适用场景：
- 快速替换单个字段的
NULL，尤其是写报表 SQL 或临时查询时 - 和
CONCAT连用避免整串变NULL：CONCAT('ID:', IFNULL(id, '0')) - 注意：
IFNULL对空字符串''不生效，只处理真正NULL；如果字段存的是空字符串而非NULL，得额外加CASE判断
NULL 值参与计算或拼接时的静默失效问题
很多用户发现 SELECT price + tax FROM orders 结果里某些行是 NULL，不是预期的数字。这不是 bug，而是 SQL 标准规定：任何值与 NULL 做算术/字符串运算结果恒为 NULL。
这时候不能只靠 COALESCE 包裹最终结果，得提前干预参与运算的每个可能为 NULL 的列：
SELECT COALESCE(price, 0) + COALESCE(tax, 0) AS total FROM orders
否则写成 COALESCE(price + tax, 0)，只要 price 或 tax 任一为 NULL，加法就提前崩了，COALESCE 根本没机会介入。
其他易忽略点：
-
WHERE col = NULL永远不成立，必须写成WHERE col IS NULL -
ORDER BY col DESC中NULL默认排最前（MySQL）或最后（PostgreSQL），需显式控制：ORDER BY col DESC NULLS LAST（PostgreSQL）或用IFNULL临时映射
性能影响：COALESCE 会不会拖慢大表查询？
单纯用 COALESCE 替换 NULL 几乎不增加开销——它只是表达式求值，不触发索引失效，也不引发全表扫描。但有两个边界情况要小心：
- 在
WHERE子句里对字段套COALESCE，比如WHERE COALESCE(status, 'active') = 'active'，会导致该列索引失效（MySQL 8.0+ 支持函数索引可缓解） - 在
SELECT中大量使用嵌套COALESCE（如COALESCE(COALESCE(a,b), COALESCE(c,d))），虽不影响执行计划，但会略微增加 CPU 计算量，上亿行时可观测到毫秒级延迟 - 真正影响性能的是误以为用了
COALESCE就能绕过NULL导致的逻辑错误，比如聚合时漏掉COALESCE，让SUM忽略整行数据
实际优化重点不在函数本身，而在理解哪些列真有可能为 NULL、哪些只是业务上“不该为空但没约束”——后者应该加 NOT NULL 约束和默认值，而不是靠查询层补救。
