维度瘦身是什么
维度瘦身指维表属性过多、更新频率差异过大时，按使用频次与变更频率把属性拆分：核心维保留高频且稳定的属性，扩展维承载低频或长文本属性，查询时按需关联。另一条手段是把低基数的长文本换成编码引用，用一张小字典表替代重复存储。目标是控制行宽与更新成本，而不是把表拆得越碎越好。
基本信息
| 拆分依据 | 属性使用频次与变更频率 |
|---|---|
| 典型形态 | dim_xxx 核心 + dim_xxx_ext 扩展 |
| 编码替代 | 长文本属性换字典键，字典单独维护 |
| 收益 | 行窄、重刷成本低、更新互不牵连 |
| 代价 | 查询需要多一次 join，模型复杂度上升 |
典型使用场景
- 用户画像扩展：标签、偏好类属性变化频繁，单独放扩展表
- 商品详情：长文本描述与图片地址体积大，按需关联
- 低频属性隔离：一年用几次的审计字段不进核心维
- 存储与扫描优化：核心维变窄后，常用查询扫描量显著下降
- 更新解耦：扩展表高频更新不影响核心维的发布时间
- 权限隔离：敏感属性放独立表，只对有权限的角色开放
拆表与按需关联
拆表与按需关联
-- 核心维：常用且稳定的属性
dim_user -- user_sk, user_id, name, tier, city_code
-- 扩展维：低频或高频变更的属性
dim_user_ext -- user_sk, profile_json, tags, last_active_at
-- 常用口径只 join 核心维，避免宽表全量重刷
SELECT d.tier, count(1)
FROM dim_user d
WHERE d.is_current = 1
GROUP BY d.tier;
-- 需要画像时再补一次关联
SELECT d.user_id, e.tags
FROM dim_user d
JOIN dim_user_ext e ON d.user_sk = e.user_sk
WHERE d.is_current = 1;瘦身手段对照
| 手段 | 做法 | 副作用 |
|---|---|---|
| 核心与扩展拆表 | 按变更频率分表 | 多一次 join，扩展表可能缺行 |
| 长文本换编码 | 字典表 + 编码列 | 取值要先查字典，跨表需带字典 |
| 低基数枚举压缩 | tinyint 存编码 | 可读性下降，要看字典注释 |
| 父子维替代重复行 | 层级属性拆成上下级键 | 上钻路径变长 |
| 冷属性归档 | 历史值移出主表 | 回溯时需额外取归档 |
拆分要控制 join 次数：拆成五六张小表后，简单查询也要多次关联，易用性与执行效率双降。判断标准是常用口径能否只用核心维完成；若不能，说明拆错了边界。