请教一下tiflash join优化的几个问题

使用tidb查询tiflash,我使用小数据量(查一天)测试时会走broadcast join的。但是当查询日期范围变大(维度表没有变化),就变成了在tidb上的hash join。
现在这块有几个问题想请教一下:
1.请问触发join下推的条件主要都有啥?
2.现在的join下推,只是broadcast join么,有没有shuffle join或者local join的实现?
3.如果两张表都非常大,比如一个几千万条,一个几亿条。基于tidb+tiflash可以查么,还是要上tispark?
我现在的理解是如果tiflash可以做shuffle join或者local join,是不是可以通过水平扩展tiflash实现啊

现在通的版本是v4.0.8,麻烦帮忙解答一下。。

由于现在 TiDB 并不支持 MPP 所以 您说的 join 下推应该还是不能实现的
目前 tidb 支持的下推类型 可以参考 如下链接
https://docs.pingcap.com/zh/tidb/dev/expressions-pushed-down#下推到-tikv-的表达式列表

以以下的 链接的 执行计划为例
https://docs.pingcap.com/zh/tidb/dev/explain-overview

问题 1 :问题本身有问题
问题 2: 通过 确认 tidb 支持的 hint 类型 可以看到支持的 join 类型 index join、hash join、index hash join、merge join、index merge join 目前版本是关闭状态 后续版本会再开放。
https://docs.pingcap.com/zh/tidb/dev/optimizer-hints
问题 3:根据我们的经验 目前 TiDB+flash 在 宽表、星型、雪花 等模型上,主表需要聚合查询的数据量在 千万级别以上,列存 tiflash 会有优势。但是 多对多的 大表 join 因为 ,数据聚合主要受到 tidb 的限制,所以 可能出现 tidb oom 的情况 ,且不会有较好的 计算特性。此时建议使用 tispark 进行 分布式计算。
如果查询聚合的 行数 在 100w 左右 tikv 行存是更好的选择。
剧透 5.0GA 后 tidb 会支持 MPP 计算引擎。届时 join 加速将成为可能。


多谢,大体上明白了。我的问题1实际上针对文档上说的这个地方。

目前我的测试是查一天的数据会用BroadcastJoin,只是把date范围调成两天及以上就会变成在tidb的hash join。如下图所示,这个执行计划的选择是基于什么的啊,是cost,还是和分区表有关系,或者其他的?
sql:
explain analyze
select
cr.date as date,
dims.creative_account_id,
sum(cr.cost)/10000 as cost
from makepolo.vendor_creative_report cr
left join makepolo.creative_report_dims dims on dims.vendor_account_id = cr.vendor_account_id and dims.vendor_creative_id = cr.vendor_creative_id
left join makepolo.entity_vendor_account_tmp eva on eva.id=cr.vendor_account_id
where cr.date>=‘2020-12-01’ and cr.date<=‘2020-12-02’ and cr.vendor_creative_id <>‘0’ and eva.company_id in (5)
group by 1,2 order by 1,2;


这是因为 你使用的 是分区表,目前 分区表如果 是多个分区中是会 使用 hashjoin 的。可以测试下 非分区表。或者使用 union all 分别查询两个分区数据
目前的 tidb 分区表 。每个分区表相当于一张独立的表。统计信息并不能有效融合。
未来 5.0 以后的版本应该会有所改变。

好的了解了,多谢

:ok_hand: