安全，但仅用于展示层兜底；它不改变LEFT JOIN逻辑，不能补全缺失关联行，WHERE中误用会致JOIN退化为INNER JOIN，且需注意类型兼容性与数据库差异。
COALESCE在LEFT JOIN后处理NULL字段是否安全？
安全，但得看用在哪——它只改显示值，不改变JOIN逻辑本身。很多人误以为COALESCE(user.name, '未知')能“修复”丢失的关联行，其实它只是把NULL换成字符串，那行数据依然来自右表缺失，别指望靠它补出本不存在的记录。
- 适用场景：展示层兜底，比如报表、API返回时避免前端报错或渲染空白
- 不适用场景：后续还要按
name做分组、筛选或连接计算——换完还是'未知'，不是真实数据 - 性能影响极小，纯表达式计算，数据库不会因此多扫一遍表
LEFT JOIN + COALESCE组合时常见的NULL漏判现象
最典型的是把COALESCE(t2.status, 'pending')当真值参与WHERE条件，比如写成WHERE COALESCE(t2.status, 'pending') = 'active'——这会直接过滤掉所有t2为NULL的行，让LEFT JOIN退化成INNER JOIN。
- 错误示范：
WHERE COALESCE(order.status, 'draft') = 'shipped'→ 实际丢弃了所有没匹配到order的用户 - 正确做法：先用ON/AND限定关联条件，再用COALESCE做结果修饰；WHERE里判断NULL必须用
t2.id IS NULL或t2.status IS NULL - 注意：MySQL 8.0+和PostgreSQL对
COALESCE内嵌子查询支持更好，但SQLite里慎用复杂表达式，可能触发全表扫描
COALESCE和CASE WHEN在JOIN中选哪个？
优先用COALESCE，除非需要分支逻辑。它更简洁、可读性高，且几乎所有SQL方言都支持；而CASE WHEN适合多条件映射，比如把NULL、空字符串、'N/A'统一转成'unknown'。
-
COALESCE本质是“取第一个非NULL”，参数类型要兼容，否则报错：COALESCE(created_at, 'N/A')在PostgreSQL里会因timestamp vs text类型冲突失败 - 想兼容多种NULL形态？老实用
CASE WHEN t2.name IS NULL OR t2.name = '' THEN '匿名' ELSE t2.name END - Oracle用户注意：
NVL只能两个参数，COALESCE才支持多参，别混用
JOIN结果里多个字段都要填默认值，怎么写不啰嗦？
别每个字段都套一层COALESCE——既难读又容易漏。用子查询或CTE先做完JOIN，外层再统一处理，逻辑更干净。
- 推荐写法：
SELECT u.id, COALESCE(o.amount, 0) AS amount, COALESCE(o.status, 'no_order') AS status FROM users u LEFT JOIN orders o ON u.id = o.user_id
- 反模式：
SELECT COALESCE((SELECT amount FROM orders WHERE user_id = u.id), 0)→ 每行触发一次子查询，O(n²)性能灾难 - 特别提醒：如果默认值依赖其他表字段（比如用user.country决定currency），就别硬塞进COALESCE，该JOIN还得JOIN，该LEFT就LEFT
