coalesce 更适合多列回退，因其是标准sql函数，支持任意数量参数并返回首个非null值；而isnull仅限两参数且为sql server特有，嵌套case则易错难维护。
COALESCE 为什么比 ISNULL 或 CASE 更适合多列回退
COALESCE 是标准 SQL 函数，能接受任意数量参数并返回第一个非 NULL 值，天然适配「从左到右逐列 fallback」的场景。ISNULL 只支持两个参数且是 SQL Server 特有；手动写嵌套 CASE 容易出错、可读性差，尤其当列数超过 3 时维护成本陡增。
常见错误现象：COALESCE(col1, col2, col3) 返回 NULL —— 实际上说明这三列全为 NULL，不是函数失效，而是数据本身无有效值。别急着改逻辑，先查 SELECT col1, col2, col3 FROM table WHERE id = X 确认原始数据状态。
实际写法中必须注意的参数类型一致性
所有传入 COALESCE 的参数必须能隐式转换为同一数据类型，否则报错 Operand data type varchar is invalid for max operator（常见于混合 INT 和 VARCHAR）。SQL Server 会按数据类型优先级决定最终类型，但结果可能不符合预期。
SELECT COALESCE(age, 'N/A') FROM users;会失败：因为
age 是 INT，'N/A' 是 VARCHAR，SQL Server 尝试把 'N/A' 转成 INT 导致转换错误。
- 正确做法：统一显式转为字符串——
COALESCE(CAST(age AS VARCHAR), 'N/A') - 或统一转为数字（如果业务允许）——
COALESCE(age, -1) - PostgreSQL 更严格，连
TEXT和CHAR混用都可能触发类型不匹配
在 JOIN 和子查询里用 COALESCE 回退要防 NULL 传播
当 COALESCE 用于关联字段（如 ON COALESCE(t1.code, t1.alt_code) = t2.code），若 t1.code 和 t1.alt_code 都为 NULL，则整个表达式为 NULL，导致该行无法匹配任何 t2 记录——这是 NULL 语义决定的，不是 bug。
使用场景：你希望「只要任一编码可用就尝试关联」，但实际效果是「全空则跳过关联」。这时得确认业务是否接受丢失这部分数据。
- 若需强制保留记录，改用
LEFT JOIN+COALESCE在 SELECT 子句中处理，而非 ON 条件中 - 若必须在 ON 中 fallback，可加兜底常量：
COALESCE(t1.code, t1.alt_code, 'DUMMY')，但要确保'DUMMY'不会误匹配t2.code - MySQL 8.0+ 支持函数索引，但
COALESCE(col1, col2)无法直接走索引，需要单独建函数索引
性能影响和替代方案取舍
COALESCE 本身开销极小，但滥用会导致执行计划劣化：比如在 WHERE 条件中写 WHERE COALESCE(status, 'active') = 'active'，数据库无法使用 status 列上的索引，变成全表扫描。
容易被忽略的地方：很多开发者以为「只是换个默认值」就无性能代价，其实只要出现在过滤条件或 JOIN 条件中，就可能绕过索引。这时候更稳妥的做法是：
- 拆成
WHERE status = 'active' OR (status IS NULL AND 'active' = 'active')—— 看似啰嗦，但能让优化器识别索引可用性 - 或提前在应用层/ETL 中补全默认值，避免运行时计算
- PostgreSQL 可用
COALESCE(status, 'active') = 'active'配合表达式索引，但 MySQL 不支持
