LEFT JOIN 本身不填充缺失值，仅暴露右表无匹配时的NULL；真正补全需用COALESCE等函数显式处理每列，默认值须类型兼容且避免冗余包裹。
Left Join 为什么不能直接“填充”缺失值
Left Join 本身不修改数据，它只是按条件关联两张表并保留左表全部行。如果右表（维度表）没有匹配记录，对应字段会自然变成 NULL——这不是“缺失值被填充”，而是“暴露了缺失”。想真正填充，必须在 Join 后用 COALESCE、CASE WHEN 或默认值逻辑显式处理。
常见错误是写完 LEFT JOIN dim_customer ON f.customer_id = dim_customer.id 就以为维度字段已补全，结果发现 dim_customer.name 大量为 NULL，后续聚合或导出时报错或失真。
用 COALESCE 在 Left Join 后安全兜底
最常用也最直观的方式：对每个可能为 NULL 的维度字段，用 COALESCE 提供默认值。注意它只作用于单列，且按参数顺序取第一个非 NULL 值。
-
COALESCE(dim_product.category, 'Unknown')—— 优先用维度表值，空则填字符串 -
COALESCE(dim_date.fiscal_quarter, 'Q0')—— 数值型字段兜底需类型一致，否则可能报错 - 避免嵌套过深：
COALESCE(a, COALESCE(b, c))等价于COALESCE(a, b, c)，直接平铺更清晰
示例片段：
SELECT f.order_id, COALESCE(d_cust.name, 'Customer Not Found') AS customer_name, COALESCE(d_prod.brand, 'Brand Unknown') AS brand FROM fact_orders f LEFT JOIN dim_customer d_cust ON f.customer_id = d_cust.id LEFT JOIN dim_product d_prod ON f.product_id = d_prod.sku;
Left Join 多次失败时该检查什么
如果 COALESCE 后仍有大量默认值，说明 Left Join 没匹配上——不是语法问题，而是数据质量问题。优先排查以下三点：
- 连接字段类型不一致：比如
fact_orders.customer_id是VARCHAR，而dim_customer.id是INT，隐式转换失败导致全不匹配 - 存在不可见字符：源系统导入时带入空格或换行符，用
TRIM()或REPLACE(col, CHAR(10), '')清洗后再 Join - 业务主键未对齐：例如事实表用的是旧版客户编码，维度表已迁移到新 ID，需先通过映射表做中间转换，不能硬 Join
临时验证方式：加 WHERE d_cust.id IS NULL 查看哪些 customer_id 在维度表里确实不存在，再针对性补维或修正 ETL 流程。
性能与可维护性提醒
在大事实表上频繁用 COALESCE 不影响 Join 性能，但若维度字段本身有索引，而你又对 COALESCE(dim_col, 'default') 做了 WHERE 或 GROUP BY，数据库很可能放弃索引走全表扫描。
更隐蔽的问题是维护成本：当维度表新增字段（如 dim_customer.segment），很容易忘记在事实查询里补上对应的 COALESCE，导致下游误读 NULL 为有效值。建议把这类逻辑下沉到物化视图或预建的星型模型视图中统一管理，而不是每次写即席查询都手写一遍兜底。
