COALESCE不能跨表“一键兜底”，仅对括号内已有字段值做NULL判断；必须逐字段用COALESCE处理并带明确表前缀，且确保NULL真实来自外连接结果，否则兜底失效。
COALESCE 必须逐字段包裹，不能跨表或跨列“一键兜底”
很多人以为写个 COALESCE(t2.name, t3.title) 就能自动从右表中挑一个有值的字段，其实这是错的——COALESCE 只判断它括号里**当前表达式列表**的值，而 t2.name 和 t3.title 是两个独立来源，如果 t2 没匹配上，t2.name 是 NULL；如果 t3 也没匹配上，t3.title 也是 NULL；但 COALESCE(t2.name, t3.title) 本身不会“触发”对 t3 的关联逻辑，它只做值判断。
正确做法是：每个字段单独用 COALESCE 处理，且确保字段名带明确前缀（如 t2.name、t3.title），避免歧义。
-
COALESCE(t2.name, 'guest')—— 处理用户表缺失时的姓名 -
COALESCE(t3.title, 'no dept')—— 处理部门表缺失时的标题 - 不要写成
COALESCE(t2.name, t3.title, 'N/A')，除非你确认这两个字段在语义上可互换（极少见）
LEFT JOIN 条件写错会让 COALESCE 彻底失效
COALESCE 生效的前提是字段**真为 NULL**，而这个 NULL 必须来自 JOIN 本身的外连接行为。一旦你在 ON 子句里加了右表过滤条件，比如：
LEFT JOIN departments t3 ON u.dept_id = t3.id AND t3.status = 'active'
那 t3.title 就永远不会是 NULL（不满足 status = 'active' 的行直接被排除），COALESCE(t3.title, 'inactive') 就永远返回原值，起不到兜底作用。
- 把业务过滤条件移到
WHERE或子查询里（注意：放到WHERE会退化 LEFT JOIN，慎用） - 更安全的做法是先用子查询预过滤右表：
LEFT JOIN (SELECT id, title FROM departments WHERE status = 'active') t3 ON u.dept_id = t3.id - 验证方法：先跑一遍不带
COALESCE的查询，SELECT u.name, t2.email, t3.title，确认目标字段确实出现NULL
聚合 + 多重 LEFT JOIN 时，COALESCE 要放在 COUNT 外层
比如用日期维表左连订单表再左连用户表，想统计每天下单用户数，结果某些日期显示 NULL 而不是 0，问题往往出在两处：
-
COUNT(t2.order_id)是对右表字段计数，没匹配时返回0，但若你写了COUNT(*)，它会统计左表行数（哪怕右表全空），导致数值失真 -
COALESCE必须包在聚合函数外面：COALESCE(COUNT(t2.order_id), 0)，而不是COUNT(COALESCE(t2.order_id, 0))（后者语法错误） -
GROUP BY必须只用左表字段（如dim_date.date），否则 NULL 组会被拆开或丢失
别指望 COALESCE 补齐“根本没数据的维度”，比如某天连日期维表都没记录（非连续生成），那得靠生成日期序列或补全维表，不是加个函数能解决的。
类型不兼容会导致 COALESCE 直接报错
COALESCE 要求所有参数能隐式转成同一类型，否则数据库会拒绝执行。典型翻车场景：
-
COALESCE(t2.id, t3.code)—— 若t2.id是INT，t3.code是VARCHAR，PostgreSQL/SQL Server 会报错，MySQL 可能静默转成字符串但结果不可控 -
COALESCE(t2.created_at, 'N/A')—— 时间戳和字符串无法共存，必须统一转成字符串：COALESCE(TO_CHAR(t2.created_at, 'YYYY-MM-DD'), 'N/A')（PostgreSQL）或COALESCE(DATE_FORMAT(t2.created_at, '%Y-%m-%d'), 'N/A')（MySQL） - 不确定类型时，显式转换最稳：
COALESCE(CAST(t2.score AS TEXT), '—')
最容易被忽略的是：多层嵌套 JOIN 中，你可能以为 t3.name 存在，但它依赖 t2 是否存在；如果 t2 没匹配，t3 根本不会参与连接，t3.name 就是 NULL —— 这时候 COALESCE 才真正有用，但也正因如此，你得一层层检查每张右表是否真的被连上了。
