sql执行很慢,不正常的慢


sql执行很慢,要20分钟才能出结果,但是CLUSTER_TIDB_TRX表显示state是idle,是什么原因呢

看看dashboard页面sql慢在哪。。。

什么样的sql慢,是所有的还是个别的

个别的,能给看看执行计划嘛

执行计划发出来看看

1 个赞

sqlplan.txt (87.1 KB)

这一步是在做什么?看资料这一步还不能下推到tikv :joy:

1 个赞

| ├─IndexRangeScan_340(Build) | 1.28 | 41354 | cop[tikv] | table:ac_value_mapping_config, index:uniq_code(mapping_group, mapping_code, in_col1_value) | time:255h44m54.2s, loops:835492652,

loops:835492652

数据量才4w,但循环了8亿次,sql这里肯定写的有问题。是不是没有做表连接,所以做笛卡尔积了。
如果没有起别名的话,表名是ac_value_mapping_config。重点看看。

把业务需求场景描述一下 把sql脱敏后贴出来

明显都慢在ps_accounting.ac_value_mapping_config这个表了,看下这个表的过滤条件和关联条件

么有过滤吧,笛卡尔积。

1、看执行计划└─Apply_63能够看出来这个是子查询,所以并非笛卡尔积问题。
2、看├─IndexRangeScan_340中的decided by [eq(ps_accounting.ac_value_mapping_config.mapping_group, czhaoshang) eq(ps_accounting.ac_value_mapping_config.mapping_code, czhaoshang_district_mapping) eq(ps_accounting.ac_value_mapping_config.in_col1_value, ps_accounting.ac_std_order_address.city_code)] 可以看到这个是关联子查询,结合1可以知道并没有解关联。
3、看├─IndexRangeScan_340的索引uniq_code和└─MaxOneRow_336可以看出来这个索引是唯一索引,这个根据├─Projection_64的actRows=41354以及├─IndexRangeScan_340的max_proc_keys:1和otal_process_keys: 41354更加认证了这一点。
4、所以这个关联子查询虽然在└─Apply_63走了CARTESIAN left outer join但是效率并不会慢的太离谱,因为Build端(├─Projection_64)总记录数才41354行,因此我理解这个语句怎么也不应该执行20m33s。
5、看├─IndexRangeScan_340中的cop_task的num: 41354可以知道去tikv请求数据时候并没有问题,看tikv_task执行也相当正常,但是该算子的执行时间相当离谱:time:255h44m54.2s, loops:835492652。为何会loops这么多次呢?正常来说数据库内部调用一次Next请求就会一个loop操作,一个Next请求是一个chunk数据(代表一行或者多行数据)。这里最大的问题是子查询为何会空跑Next请求且严重耗时,我更感觉这是产品的问题。

2 个赞

你还是厉害的。 :+1:

虽然最后结论还不确定。可能是子查询处理的时候产生的,不一定是人为的。但笛卡尔积的存在是确定的。

https://docs.pingcap.com/zh/tidb/stable/analyze-slow-queries#做了笛卡尔积的-join

前对于产生笛卡尔积的 Join 会在执行计划中显示的标明 CARTESIAN

解决了吗

我理解对于关联子查询都会加上CARTESIAN字样,因为实际执行时候是用的关联算法(类似于lookupjoin)但是又是子查询并非join(只有解关联后才会join形式),所以on condition是空,执行计划就会加上CARTESIAN字样。
正常的join有CARTESIAN说明真正发生了笛卡尔积了(两种原因:1、on condition缺失,2、 非not null定义的反半连接关联子查询解关联后也会有笛卡尔积,这个在6.3版本已经优化了增加了Null-Aware Semi Join能力,但还没有默认开启,因为tiflash不支持,在7.1版本应该都支持了。https://docs.pingcap.com/zh/tidb/stable/explain-subqueries#null-aware-anti-semi-joinnot-in-和--all-子查询 ,相关问题帖子:一个 tidb 无索引查询性能问题请教 参考阿毛哥的最佳答案)

还有一种“局部”笛卡尔积,在执行计划中不标识CARTESIAN,比如部分数据匹配严重多对多,执行计划上可能看不出来但是内部执行时候会发生笛卡尔积。

2 个赞

只能等楼主吧语句发出来看看了

1 个赞