LEFT JOIN能补全维度数据是因为它保留左表所有行，右表无匹配时字段置为NULL，从而暴露缺失维度；需将过滤条件置于ON子句、用COALESCE填充默认值、确保索引及时间戳逻辑正确，并通过检查定位真实缺数原因。
LEFT JOIN 为什么能补全维度数据
因为 LEFT JOIN 会保留左表所有行，右表匹配不到的字段自动填充为 NULL，这正是“补全”的起点——你把主事实表放左边，把维度表（比如地区、品类、用户标签）放右边，缺失的维度自然就暴露为 NULL，后续可统一用 COALESCE 或 CASE 填默认值。
补全时必须注意 ON 条件的写法
常见错误是把过滤条件写在 WHERE 里，导致 LEFT JOIN 变相退化成 INNER JOIN。例如想补全“所有订单+对应用户等级”，但又在 WHERE 加了 user.level = 'VIP'，结果没等级的订单直接被筛掉了。
- 维度过滤必须写在
ON子句中：ON orders.user_id = users.id AND users.status = 'active' - 若需保留所有订单并只对活跃用户补等级，
users.status = 'active'就得放在ON；若放WHERE，所有users为NULL的订单都会消失 - 多维度补全时，每个
LEFT JOIN的ON应独立判断，不要共用一个条件
用 COALESCE 处理 NULL 维度值更安全
COALESCE 比 IFNULL 或 ISNULL 更通用（标准 SQL 支持），且支持多个备选值。补全不是为了留着 NULL，而是让下游分析不报错、图表不崩。
SELECT orders.order_id, COALESCE(users.region, '未知地区') AS region, COALESCE(products.category, '未分类') AS category, orders.amount FROM orders LEFT JOIN users ON orders.user_id = users.id LEFT JOIN products ON orders.product_id = products.id
- 避免直接用
users.region || '未知地区'—— 多数数据库中NULL || 'x'结果仍是NULL - 如果维度表有历史变更（如用户迁移到新区域），要确认
JOIN条件是否带时间戳，否则可能补错快照 - 补全后建议加检查：
WHERE users.region IS NULL查哪些订单真没匹配上，而不是被逻辑误筛
性能隐患：大维度表 + 高基数关联字段
当维度表超千万行、关联字段（如 user_id）区分度极高时，LEFT JOIN 可能变慢，尤其在没有索引或统计信息过期的情况下。
- 确保右表关联字段有索引：
CREATE INDEX idx_users_id ON users(id) - 避免在
ON中对字段做函数操作，如ON UPPER(orders.code) = UPPER(dim.code)，会跳过索引 - 某些场景下，先用
SELECT DISTINCT提取左表唯一键去预查维度，再反向JOIN，比直接大表LEFT JOIN更快
补全本身很简单，难的是想清楚“缺的是什么”——是数据没录？同步延迟？还是关联逻辑错了？LEFT JOIN 只负责暴露空缺，定位根因还得看上游链路和业务语义。
