我有一个像这样的查询
sel
tb1.col1,
tb4.col2,
(case WHEN t4.col4 in (<IN LIST with more than 1000 values!>) then T4.Col7
Else "Flag" ) as "Dcol1",
Sum ( tb3.col1),
sum (tb3.col2 ),
sum (tb2.col4)
etc
from
tb1 left outer join tb2 <condition> LOJ tb3 <conditions>
where tb1 condition and tb2 condition and tb3 condition
group by ( case <condition> , colx.tb2,coly.tb1
问题是 TB3 和 TB4 是巨大的事实表。事实表的 PI 不包含在此处的连接或查询中。
到目前为止我做了什么
是创建一个 volatile 表(与 IN LIST 相同的 pi)并尝试实现。VT1 具有与 TB4 相同的 PI,并将在 where 子句中包含 IN LIST。我喜欢这个使用方法
select
....
CASE WHEN Dtb1.c1 IS NOT NULL
THEN ft."CustomColumName"
ELSE 'ALL OTHER'
end as "CustomColumName"
from "Db"."FACTTablew5MillionRows" as ft
left join VolatileTable Dtb1
on Dtb1.c1=ft.C1
我如何优化这些类型的查询假设 tb3 和 tb2 是巨大的事实表。PI TB3 是 C4,c6 和 tb2 的 PI 是 C6,C7 TB3 有一个分区列 Cp,但不用于任何类型的 where 子句。它用于其中一个连接,他们没有相同的 PI,但可能在他们的 PI 中有一个共同的列 TB3 的行数约为 8000 万行,6000 万行。原始查询根本不会在没有假脱机的情况下运行。幸运的是,它可以在晚上使用 80K Impact C。只有在创建具有与 tb2 相同的 PI 的 VT2 然后使用它加入之后,我才能让查询在 < 200 Impact 中运行。我不想创建一堆 VT 供了解 TD 深蹲的 BO 用户使用。我能做些什么来让这个 Q 变得更好