coalesce按从左到右顺序返回第一个非null值，参数顺序写反（如coalesce('n/a', col)）会导致空值无法被替换；它仅识别null，不处理空字符串或0，且所有参数须类型兼容。
COALESCE参数顺序写反会导致空值没被替换
COALESCE不是“选非空”，而是“从左到右取第一个非NULL值”。如果把可能为NULL的字段放在右边，而左边是常量（比如'N/A'），那它永远返回左边——空值根本不会被处理。
常见错误现象：COALESCE('N/A', col) 总是返回 'N/A'，哪怕 col 是 123；反过来 COALESCE(col, 'N/A') 才符合直觉。
- 必须确保第一个参数是可能为NULL的表达式，后续才是备选值
- 多个备选值会逐个判断：例如
COALESCE(col1, col2, 'fallback')，只有col1和col2都为NULL时才用'fallback' - MySQL 8.0+、PostgreSQL、SQL Server 都支持，但 SQLite 的
COALESCE行为一致，无需额外适配
COALESCE在WHERE子句中让索引失效
写成 WHERE COALESCE(name, '') = 'Tom' 看似简洁，但数据库无法直接使用 name 字段上的索引——因为函数包裹后，优化器得对每行先计算再比对，大表上极易触发全表扫描。
真实执行计划里常看到 type: ALL 或 key: NULL，就是这个原因。
- 安全写法是拆开：
WHERE (name = 'Tom') OR (name IS NULL AND '' = 'Tom')，但后者恒假，实际简化为WHERE name = 'Tom'——所以更推荐提前清洗数据，把NULL统一转成'' - 若业务真要查“空或等于某值”，且字段已有索引，优先建函数索引（MySQL 8.0+）：
CREATE INDEX idx_name_coalesce ON t1 ((COALESCE(name, ''))) - 别在JOIN的
ON里用COALESCE做连接字段转换，比如ON u.id = COALESCE(o.user_id, -1)，这会让o.user_id上的索引完全失效
COALESCE返回类型由第一个非NULL参数决定
类型隐式转换容易引发排序错乱、聚合异常或插入失败。比如 COALESCE(int_col, 'N/A') 会让整列变成字符串类型，ORDER BY 就按字典序排：10 排在 2 前面。
典型报错：Data truncated for column 'x' at row 1（插入时字符串往INT列塞）或 Invalid date（时间字段混了字符串）。
- 两个参数类型尽量一致：用
COALESCE(int_col, 0)，而不是COALESCE(int_col, '0') - 时间字段慎用字符串兜底：
COALESCE(created_at, '1970-01-01')可行，但COALESCE(created_at, 0)会触发隐式转成日期失败 - 不确定类型时，显式转换更稳：
COALESCE(CAST(int_col AS CHAR), 'N/A')或COALESCE(TO_CHAR(created_at), 'N/A')（依数据库方言）
空字符串和NULL不是一回事，COALESCE不处理空字符串
COALESCE 只识别 NULL，对 ''、' '、0 全部原样返回。很多“看着是空”的字段其实是空字符串，导致 COALESCE(col, 'N/A') 完全没生效。
验证方法：SELECT col, LENGTH(col), DUMP(col) FROM t WHERE col IN ('', ' ', NULL)（Oracle）或 HEX(col)（MySQL）看十六进制编码。
- 要同时处理
NULL和空字符串，必须嵌套：COALESCE(NULLIF(col, ''), 'N/A') -
NULLIF(col, '')意思是“如果col等于''，就返回NULL，否则返回col”，再套一层COALESCE才真正兜底 - MySQL 用户别迷信
IFNULL(col, 'N/A')，它同样不处理空字符串，且在 PostgreSQL/SQL Server 里直接报错：function ifnull(unknown, unknown) does not exist
最易被忽略的一点：COALESCE 的逻辑是短路求值，但它的参数本身仍会被完整计算——如果第一个参数是子查询或函数调用，即使最终没用上，开销也已发生。线上大表关联时，别在 SELECT 列里无节制堆叠多层 COALESCE(NULLIF(...))。
