分区表join问题

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】

【问题】

  1. 如附件中图1所示,我在分区表上执行一个join查询的时候,分区表作为被驱动表有3个分区被查询,只有一个分区走了主键索引,另外两个分区走了全表扫描,这3个分区的查询条件是完全一样的,为什么会出现这种情况?

  2. 如附件中图2所示,我添加了/*+ INL_JOIN(r, ws) */ 的SQL Hint,执行计划反而没有按照Hint的指示执行,而是把Hint中的第一个表作为了被驱动表。

【TiDB 版本】 5.7.25-TiDB-v6.1.1

【附件】
图1:


图2:


若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

set session tidb_partition_prune_mode = ‘dynamic’; 打开动态裁剪后再试试

我们之前开启动态裁剪遇到更严重的问题: 升级6.1后,TiFlash服务异常

hint生效了的,hash join变成了index nl join,只不过驱动表顺序反了,可以再加个hint让ws表走主键索引试试,看能否纠正驱动顺序

你的另一个帖子上是动态裁剪后全表扫描或其他情况下大量的cop请求发送到tiflash造成的积压,先这个环境是那个版本升级吗? 看你现在的执行计划里走的都是tikv可以试试开启动态裁剪后,加/read_from_storage(tikv[xx])/方式强制走tikv,避免走tiflash。 不开动态裁剪的话,表关联时不能识别到关联条件值而做分区裁剪。

加了use index的hint之后还是那样,不仅驱动表的顺序没变,连ws表的查询有两个分区也还是走的全表扫描

是从6.1升到了6.1.1。

现在没法通过加 read_from_storage的hint强制走tikv,一旦开启分区裁剪,那么多的查询改不过来。

在测试环境开启分区动态裁剪的情况下查询的确是正常了:

但是线上那个在tiflash下分区裁剪的问题没有fix不敢开动态分区裁剪啊。

你可以先在会话级设置观察下开启后执行计划是否正常,全局开启确实影响比较大,原有SQL加hint可以用SPM方式绑定,但是开动态裁剪等这类的优化器相关参数tidb还不支持hint,听说官方后续会做一个变量hint ,目前只能等官方修复这个tiflash问题了。

去掉INL_JOIN,只加hint让ws走主键试试

在你之前的帖子上 官方回复了优化进度,后续全部使用mpp模式

set session tidb_partition_prune_mode=dynamic

老哥,能贴下完整SQL语句(包括变量)和完整执行计划么。

好的,等发版了

如果要手工指定 join 顺序,可以参考以下两个hint
https://docs.pingcap.com/zh/tidb/stable/optimizer-hints#leadingt1_name--tl_name-
https://docs.pingcap.com/zh/tidb/stable/optimizer-hints#straight_join