COALESCE仅在SELECT投影阶段处理已存在的NULL，不修复JOIN逻辑错误；需先验证LEFT JOIN是否真产生NULL，再确保字段来源明确、类型兼容、避免空字符串干扰，并慎用于WHERE以保索引有效。
COALESCE 不能修复 JOIN 逻辑错误，只处理已产生的 NULL
COALESCE 对 JOIN 本身没影响，它只在 SELECT 投影阶段起作用。如果你的 LEFT JOIN 结果里某字段是 NULL，那 COALESCE 可以兜底；但如果因为 ON 条件写错导致本该保留的右表行被过滤掉（比如误加了 b.status IS NOT NULL），那字段根本不会为 NULL，COALESCE 就完全没机会执行。
验证是否真有 NULL：先跑一遍不带 COALESCE 的查询，SELECT a.id, b.name FROM orders a LEFT JOIN users b ON a.user_id = b.id，看 b.name 列是否真出现 NULL 值。没有 NULL，说明 JOIN 已退化成 INNER JOIN，得先修 ON 条件。
LEFT JOIN 后对右表字段用 COALESCE 的正确姿势
必须明确字段来源、类型一致、避免空字符串干扰：
- 始终带表别名：
COALESCE(b.email, 'no-email@null')，不能只写COALESCE(email, ...)（多表同名字段会报错） - 右表字段若可能存空字符串而非 NULL，先用
NULLIF清洗：COALESCE(NULLIF(b.phone, ''), '—') - 所有参数类型必须兼容：如果
b.score是numeric，默认值就得写0.0，不能写0（PostgreSQL 拒绝隐式转整型） - 别在 ON 或 WHERE 里套 COALESCE——它不改变连接行为，只影响最终输出
多层 JOIN 时 COALESCE 必须逐列独立包裹
COALESCE 返回单个标量值，不能“跨表自动对齐”。例如连查 orders → users → profiles，想给用户昵称和头像分别兜底，不能写成 COALESCE(u.nickname, p.avatar)（类型不匹配且语义错乱）。
正确写法是分开处理：
SELECT o.order_id, COALESCE(u.nickname, u.username, 'guest') AS display_name, COALESCE(p.avatar_url, '/static/default-avatar.png') AS avatar FROM orders o LEFT JOIN users u ON o.user_id = u.id LEFT JOIN profiles p ON u.id = p.user_id;
注意顺序：优先级高的字段放左边，比如昵称比用户名更倾向展示。
WHERE 中误用 COALESCE 导致索引失效
常见错误：WHERE COALESCE(b.status, 'pending') = 'active'。这会让数据库放弃使用 b.status 上的索引，因为表达式无法直接命中索引键。
等价且高效写法是拆开逻辑判断：
-
WHERE b.status = 'active'（直接走索引） - 如需同时匹配 NULL 状态，改用：
WHERE b.status IS NULL OR b.status = 'active' - 若业务上 NULL 和
'pending'等价，且查询高频，可建函数索引：CREATE INDEX idx_status_coalesce ON users ((COALESCE(status, 'pending')))
复杂兜底逻辑（比如要区分 NULL、空字符串、非法值）建议换 CASE，别硬塞进 COALESCE —— 它不是万能条件引擎，只是短路取值工具。
