Star Join 不生效是因为三个硬性条件缺一不可：事实表外键列需有位图索引、STAR_TRANSFORMATION_ENABLED必须设为TRUE、维度表连接列须有主键或唯一约束；任一缺失均导致优化器跳过星型转换，执行计划仍为全表扫描。
Star Join 在 Oracle 中为何不生效？三个开关缺一不可
Star Join 不是自动触发的优化，它依赖三个硬性条件同时满足：事实表外键列上必须有 BITMAP INDEX、STAR_TRANSFORMATION_ENABLED=TRUE、维度表连接列（通常是主键）要有 PRIMARY KEY 或 UNIQUE 约束。少一个，执行计划里就看不到 STAR TRANSFORMATION 或 BITMAP MERGE，只会走全表扫描。
常见错误现象包括：明明在 SALES.CUST_ID 上建了位图索引，WHERE 条件也用了 CUSTOMERS.CUST_STATE_PROVINCE = 'CA'，但 EXPLAIN PLAN 仍显示 TABLE ACCESS FULL on SALES——根本原因不是索引没建对，而是优化器压根没进入星型转换路径。
检查方式很简单：
- 运行
SHOW PARAMETER star_transformation_enabled，默认是FALSE，不改等于关着门干活 - 确认维度表主键是否真实存在：
SELECT constraint_type FROM user_constraints WHERE table_name = 'CUSTOMERS' AND constraint_name = 'CUSTOMERS_PK'; - 位图索引必须建在事实表外键列，不是维度表主键列：
CREATE BITMAP INDEX sales_cust_bix ON SALES(CUST_ID) LOCAL;才有效；CREATE BITMAP INDEX cust_pk_bix ON CUSTOMERS(CUST_ID);没用
PostgreSQL 星型模型下 JOIN 性能差，先看统计信息和分区
PostgreSQL 没有 Star Join 优化机制，但它对星型查询的响应能力高度依赖两件事：统计信息是否新鲜、事实表是否合理分区。没有 ANALYZE 过的表，优化器大概率选错连接顺序，把大事实表当驱动表，JOIN 变成嵌套循环地狱。
实操建议：
- 每次加载新分区后立即执行
ANALYZE sales_fact PARTITION (p2026_q2);，别只ANALYZE sales_fact;—— 分区级统计更准 - 事实表按时间字段（如
sale_date）范围分区，避免单表膨胀到亿级后 JOIN 效率断崖下跌 - 维度表务必加
PRIMARY KEY，并确保 JOIN 条件严格匹配（比如ON f.product_id = d.product_id，不能写成ON f.product_id::text = d.product_id::text） - 小维度表（pg_hint_plan 强制
HashJoin，但仅限调试，上线前应靠数据分布和索引解决
Doris 中多表 JOIN 查询慢？优先建物化视图而非调优 SQL
Doris 的星型加速核心不在 SQL 写法，而在 MATERIALIZED VIEW 是否覆盖了常用 JOIN + 聚合路径。它会把 fact JOIN dim1 JOIN dim2 GROUP BY a,b,c 预计算并物化，后续查询直接命中，延迟降低 70%–95%。
关键点：
- 物化视图定义必须显式包含所有参与 JOIN 的表和字段，例如：
CREATE MATERIALIZED VIEW mv_sales_by_region AS SELECT f.date, d1.region_name, SUM(f.amount) FROM sales_fact f JOIN region_dim d1 ON f.region_id = d1.id GROUP BY f.date, d1.region_name; - 不能只建在单表上，否则无法加速跨表过滤（如
WHERE region_name = 'East'） - 物化视图刷新策略选
ASYNC，避免阻塞写入；但要注意增量更新后，MV 数据可能有秒级延迟 - 查询时无需改写 SQL，Doris 会自动路由到物化视图——前提是
SET enable_materialized_view_rewrite = TRUE;
为什么加了索引、开了参数，OLAP JOIN 还是慢？先确认查询模式是否匹配预设路径
所有星型加速机制都隐含一个前提：你的查询过滤条件和分组维度，正好落在预计算或索引覆盖的路径上。比如 Oracle 的位图连接索引 sales_state_bix 只对 CUSTOMERS.CUST_STATE_PROVINCE 有效，一旦换成 CUSTOMERS.CUST_CITY，哪怕也建了索引，星型转换照样被跳过。
容易被忽略的复杂点：
- 维度表字段过滤选择率太低（如
LIKE '%keyword%'），优化器认为走索引成本高于全扫，直接放弃星型路径 - 事实表外键列值分布极度倾斜（比如 95% 记录
CUST_ID = 1），位图索引失效，优化器降级为普通 B-Tree 或全表扫描 - BI 工具生成的 SQL 带大量
COALESCE()、CASE WHEN或子查询，破坏了星型转换所需的“干净 JOIN + 简单 WHERE”结构
真正卡住性能的，往往不是某条语句写得不够好，而是整条查询链路——从 BI 拖拽逻辑、SQL 生成规则、到数据库执行路径——没有对齐星型模型的物理约束。
