JOIN维度表慢的主因是索引缺失或设计不当导致嵌套循环/全表扫描；需在关联字段、顺序及查询条件匹配处建索引，避免谓词下推错误、大字段拖累及分区裁剪失效。
为什么 JOIN 维度表慢？先看执行计划里有没有走索引
星型模型里事实表动辄上亿行，维度表虽小但若没建对索引，JOIN 会退化成嵌套循环或全表扫描。重点不是“加不加索引”，而是「在哪个字段、什么顺序、配合什么查询条件」建索引才有效。
常见错误现象：EXPLAIN 显示 type=ALL 或 rows 接近维度表总行数；CPU 持续高，但磁盘 I/O 不高——说明在内存里暴力匹配。
- 维度表的主键（如
dim_customer.customer_id）必须是PRIMARY KEY或至少带唯一索引，否则优化器不敢用ref访问方式 - 事实表上的外键字段（如
fact_sales.customer_id）必须单独建索引——即使它只是普通列，不参与主键 - 如果常按
date_key+product_id联合过滤再JOIN，优先建复合索引(date_key, product_id)，而不是只给product_id单列索引 - MySQL 8.0+ 和 PostgreSQL 支持函数索引，但别在
JOIN条件里写UPPER(dim.name)这类表达式，会直接让索引失效
LEFT JOIN 维度表却返回空？检查 NULL 值和谓词下推陷阱
星型模型常用 LEFT JOIN 保事实表完整性，但一旦在 WHERE 子句里对维度字段加非空判断（比如 WHERE d.region = 'US'），就等价于 INNER JOIN，丢失无匹配维度的事实行。
使用场景：报表要统计所有订单（含客户信息缺失的），但只想看美国地区的销售明细——这两者目标冲突，不能靠一个查询硬凑。
- 把维度表的过滤条件从
WHERE挪到ON子句：写成LEFT JOIN dim_customer d ON f.customer_id = d.id AND d.region = 'US' - 确认维度表中关联字段是否允许
NULL：如果fact_sales.customer_id是NULL，而dim_customer.id是NOT NULL，那这条LEFT JOIN必然产生NULL维度字段，不是 bug 是预期行为 - PostgreSQL 的
JOIN顺序会影响谓词下推，MySQL 则基本固定驱动表为左表；若发现执行计划里维度表被当驱动表，说明优化器误判了基数，可加STRAIGHT_JOIN强制
维度表太大（比如地址、描述字段很长）？考虑垂直拆分或物化冗余
维度表不是越“规范”越好。像 dim_product 里塞了 200 字的 description、HTML 格式的 spec_json，每次 JOIN 都要把整行读进内存，拖慢事实表扫描速度，还浪费 buffer pool。
性能影响比想象中更直接：MySQL InnoDB 的二级索引包含主键值，如果主键是 UUID，又带大字段，索引体积爆炸，缓存命中率骤降。
- 把高频用于
JOIN和GROUP BY的字段（如category_id、brand_code）单独拎出来建轻量级维度表，名字可以叫dim_product_light - 在事实表里冗余关键维度属性（如
sales_order.product_category），前提是该属性变更频率低（比如年更）、且业务能接受几小时延迟 - 避免用
TEXT或JSON类型存维度主键字段——它们无法被高效索引，JOIN时只能走全表比较
分区事实表后 JOIN 维度表变慢？注意分区裁剪是否生效
按 date_key 分区的事实表，本意是查某天数据时只扫一个分区，但一旦 JOIN 维度表后执行计划显示扫描了全部分区，说明分区裁剪被破坏了。
根本原因往往是 JOIN 条件或 WHERE 条件里用了非确定性函数，或者维度表过滤条件触发了“先 JOIN 再过滤”的执行路径。
- 确保
WHERE中的日期过滤用的是字面量或参数（如WHERE f.date_key = 20240501），别用DATE_SUB(CURDATE(), INTERVAL 1 DAY)这类运行期才计算的表达式 - MySQL 对
IN (SELECT ...)子查询做分区裁剪支持有限，换成JOIN或显式列出分区值更稳 - 查看
EXPLAIN PARTITIONS输出里的partitions列，如果不是只列了目标分区名（如p202405），而是出现NULL或全量分区名，就说明裁剪失败
最常被忽略的一点：维度表本身也建议按业务主键哈希分区（比如 8 个分区），尤其当它超过 500 万行时——不是为了裁剪，而是降低单次 JOIN 的锁竞争和 buffer pool 冲突。这步很多人觉得“维度表小不用管”，结果并发一上来，JOIN 成了热点。
