提取维度表能绕过GROUP BY性能陷阱，是因为将高基数多维分组下推至预聚合宽表或低基数维度主键，避免MySQL因无法满足多字段物理有序性而强制使用临时表和文件排序。
GROUP BY字段太多，直接查肯定慢——不是语法错，是数据库被迫做大量排序和临时表操作。
为什么提取维度表能绕过GROUP BY性能陷阱
当原始表要按 user_id, region, device_type, os_version, app_channel 5个字段分组时，即使全建了索引，MySQL仍大概率触发 Using temporary + Using filesort。因为索引无法同时满足高基数字段的物理有序性与多维过滤的局部性。而维度表（如 dim_user, dim_device）天然低基数、稳定、带业务语义，把JOIN提前做完，就能把 GROUP BY 压缩到 1–2 个主键字段上。
- 原始写法：SELECT u.region, d.os_version, COUNT(*) FROM fact_log l JOIN dim_user u ON l.user_id = u.id JOIN dim_device d ON l.device_id = d.id GROUP BY u.region, d.os_version → 索引难覆盖，执行计划必现临时表
- 优化后：SELECT region, os_version, cnt FROM pre_agg_region_os WHERE dt = '2026-05-09' → 单表点查，无GROUP BY
维度表怎么建才真正有用
维度表不是随便建个字典表就行。它得能承接聚合逻辑下推，否则JOIN反而更重。
- 字段必须是业务可解释的枚举或归类结果，比如
region不该是原始IP地址，而应是预计算好的'华东'/'华北'；os_version应合并为'iOS 17+','Android 13-14'等宽泛段 - 主键建议用代理键（
region_id,os_id），而非自然键，避免JOIN时字符串比较开销 - 维度表本身要加唯一约束：
UNIQUE KEY uk_region_name (region_name)，防止事实表JOIN时产生笛卡尔积 - 如果维度值会缓慢变化（SCD Type 2），务必在JOIN条件里带上生效时间，否则统计口径会漂移
预关联后GROUP BY还能怎么再压一压
即便用了维度表，有时仍需实时分组——比如按小时+区域+渠道看转化漏斗。这时别硬刚多字段，用“主维+辅维”分层策略：
- 第一层：只按高价值、低基数字段分组，如
GROUP BY hour, region_id，这部分建好索引后基本不触发临时表 - 第二层：把其余字段（如
utm_source,campaign_id）作为JSON聚合进一个字段：JSON_OBJECTAGG(utm_source, COUNT(*))，避免它们参与物理分组 - 第三层：若前端真要展开明细，改用异步导出或分页拉取，而不是塞进同一SQL里
- 注意：MySQL 5.7 不支持
JSON_OBJECTAGG，得用GROUP_CONCAT(CONCAT(utm_source, ':', COUNT(*)))模拟，但长度受group_concat_max_len限制
最容易被忽略的坑：JOIN顺序和NULL值穿透
维度表预关联不是加个JOIN就完事。实际中80%的“优化后还是慢”，问题出在数据质量上。
- 事实表里
user_id或device_id存在大量NULL，JOIN后整行丢失，导致统计数偏低且无法排查——应在ETL阶段补默认维度ID（如-1表示未知），并确保维度表含该记录 - JOIN顺序影响执行计划：MySQL优化器对LEFT JOIN + GROUP BY非常敏感。如果写成
FROM fact_log l LEFT JOIN dim_user u ... GROUP BY u.region，而u.region可能为NULL，会导致分组键不稳定，优化器放弃索引 - 用
EXPLAIN FORMAT=TRADITIONAL看filtered列：如果某张维度表的filtered显示10.00（即只过滤掉90%），说明JOIN条件没走索引，得检查外键字段类型是否一致（如BIGINTvsVARCHAR）
