COALESCE在WHERE中不加速过滤，但可收束空值逻辑、实现短路防错，并配合函数索引提升性能；它只处理NULL，不识别空字符串，且要求参数类型兼容。
WHERE子句中用COALESCE替代多条件判断
直接在WHERE里用COALESCE并不能“加速”过滤，反而容易引入隐式类型转换或掩盖真实意图。真正能提升可读性和执行效率的，是用它把分散的空值检查逻辑收束成单个表达式。
常见错误是这样写：
WHERE (col1 IS NOT NULL AND col1 != '') OR (col2 IS NOT NULL AND col2 != '')
这不仅冗长，还可能让优化器放弃使用索引。换成COALESCE前，先确认你真正想过滤的是“所有备选字段都为空/NULL”的记录——这才是它的发力点：
-
COALESCE本身不走索引，但可以简化谓词结构，便于后续加函数索引（比如CREATE INDEX ON tbl ((COALESCE(col1, col2)));） - 必须确保所有参数类型兼容，否则报错：
COALESCE(col1::TEXT, col2::TEXT)比裸写更安全 - 别用
COALESCE(col1, '') = ''代替col1 IS NULL OR col1 = ''——语义不同，且前者无法利用col1上的普通B-tree索引
用COALESCE实现短路求值避免运行时错误
当WHERE条件里涉及可能报错的表达式（如除零、类型转换失败），COALESCE的短路特性可防止后续参数被计算。这是它在过滤场景下少有人知但极实用的技巧。
例如，要查“折扣率有效且净价大于0”的商品，但discount_rate可能是NULL或0：
WHERE COALESCE(discount_rate, 0) > 0 AND price * (1 - COALESCE(discount_rate, 0)) > 0
注意：这里COALESCE只用于兜底，真正起过滤作用的是后面的比较。关键点在于：
- 如果
discount_rate为NULL，COALESCE(discount_rate, 0)返回0，整个条件自然为假，不会走到price * (1 - 0)的计算 - 但若写成
discount_rate > 0 AND price / discount_rate > 0，遇到discount_rate = 0就会直接报错 - 这种写法不能替代
NULLIF，二者用途不同：NULLIF(x, 0)是防除零，COALESCE(x, 0)是防NULL
配合函数索引把COALESCE结果持久化
单纯在WHERE里调用COALESCE不会提速，但你可以把它“固化”进索引。PostgreSQL允许对表达式建索引，只要表达式是IMMUTABLE的。
假设你总要查“有有效联系信息的用户”，而联系信息来自三个字段：
CREATE INDEX idx_users_contact ON users (COALESCE(phone, email, wechat));
之后这个查询就能走索引：
SELECT * FROM users WHERE COALESCE(phone, email, wechat) IS NOT NULL;
注意限制：
- 所有参与
COALESCE的字段必须是同一类型，或能被隐式转为同一类型；否则建索引会失败 - 如果字段含
TEXT和VARCHAR，建议显式转为TEXT：COALESCE(phone::TEXT, email::TEXT, wechat::TEXT) - 函数索引不支持
NULL值存储（B-tree索引跳过NULL），所以IS NOT NULL条件天然高效，但= 'xxx'需确保值确实存在于索引项中
别混淆COALESCE和空字符串处理
COALESCE只处理NULL，对空字符串''或纯空格' '完全无感。很多性能问题其实源于没分清这两者。
比如想过滤“实际无内容”的地址字段：
- ❌ 错误：
WHERE COALESCE(address, '') != ''—— 如果address是''，COALESCE仍返回''，条件为假，但你本意是排除空字符串 - ✅ 正确组合：
WHERE NULLIF(TRIM(address), '') IS NOT NULL—— 先去空格，再把空字符串转为NULL，最后判非空 - 如果必须用
COALESCE，得提前清洗：WHERE COALESCE(NULLIF(TRIM(address), ''), 'N/A') != 'N/A'
最易被忽略的一点：类型隐式转换可能让COALESCE悄悄变慢。比如COALESCE(int_col, '0')会触发int_col转TEXT，导致索引失效。始终显式声明类型，尤其在WHERE和索引定义中。
