tidb某些sql查询速度不如mysql

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:

【TiDB 版本】
v4.0.0
【问题描述】

一个很简单的查询,tidb的速度并不如mysql或者二者速度差不多
explain analyze如下图
image
要是按照actrows来看其实并不应该慢,但该查询耗时接近3S,mysql耗时为2秒多

select * from table_name where create_time > date_sub(now(), interval 3 day) and column_1 is null and (column_2 > 0 or column_3>0)
只有create_time字段是走索引的,整张表数据1000万,最终查询出的数据为1条


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

image
按照我的理解TableRowIdScan应该扫描一行这个数据就快了

  1. 反馈下explain analyze sql 吧, 多谢。如果有 mysql 的可以一起反馈下,多谢。
  2. 确保当前 tidb 表的 healthy 都正常。

索引是否包含 column_1,2,3 列,如果只有 create_time 列,且 mysql 也是走这个列的索引,那还需要二次回表,并且 tidb 到 tikv 回表的代价更高,可以考虑建联合索引在 index 上面过滤更多数据类似 mysql ICP,减少回表请求;就目前的这个执行计划,也可以单纯调大 tidb_index_serial_scan_concurrency 并发以加快 index scan 速度。

索引不包含1,2,3列,这个mysql的执行计划,就是create_time字段,满足create_time字段的大概是69万行,然后满足1,2,3列的有1行数据,然后再对这一行数据进行回表,这样只有1条数据的数据传输,但是看上面我的explain analyze截图,IndexRangeScan筛选出69万行数据(actRows),然后Selection10这个操作筛选出1行数据(这个是1,2,3列的筛选条件),但是最后的TableRowIdScan还是69万行,我感觉这里要是1行就会快很多,会和mysql有明显的速度差别了,我的理解这69万行都是要通过tikv传送到tidb上的吧,所以这才造成速度慢

2.tidb表的healthy如何查看
1.不好意思啊,因为是线上的东西,所以我需要截图打码,你看我下面的解释清楚么,如果不清楚您再2告诉我

最好还是反馈下建表语句和explain analyze sql 的结果。如果不行,参考楼上先试试调大参数吧。

好的,感谢,抱歉不能把这个建表语句提供出来,我的理解就是传输速度的影响吧,因为从tikv传输到tidb的数量可能比较多

这个图不全,需要看下 explain analyze sql 时间主要消耗在哪里,才比较好判断,或者先把完整的 explain analyze sql 结果发出来

tidb中执行计划:


mysql的执行计划:

根据 tidb 的执行计划看时走的 indexlookup ,最后是没有任何一行满足条件吗? 查出来的值是0行?

对,最后查出来的结果是0行,所以这块不太理解,因为没有联表,如果条件筛选都是在tikv层进行的话,最后tikv上传到tidb的结果是0条,网络传输速度快慢不会有影响,还是说每一个条件筛选出来的结果都会从tikv上传到tidb,然后在tidb层针对三个条件进行聚合

查询sql是在哪里进行的? tidb-server 还是其他安装了mysql 客户端的机器? 能否试试在 tidb-server 查询看看消耗时长

tidb-server是指在tidb-server的机器上用mysql客户端链接还是指什么

是的,想确认下从 tidb-server 节点查询此 sql 的耗时。
另外 ping 一下 tidb-server 节点到 tikv-server 节点的延时。

1.我试了,在tidb-server节点做sql查询耗费2.3 - 3秒
2.tidb-tikv的ping的速度为
(共有三台tikv)
到其中两台的速度为0.3-0.6ms之间
到另一台的速度不足0.1ms

可以根据执行计划来分析慢的原因,另外,asktug 上有读流程排查相关的帖子,可以搜一下,看一下

可以参考这里,进行读性能慢的排查

可以找个业务低峰期,试试调大参数吗?在 session 级别测试下
https://docs.pingcap.com/zh/tidb/stable/system-variables#tidb_index_lookup_size

感谢三位大佬,我稍等分析下再回复,目前我能确定不是业务高峰期的问题,不是网络问题,服务器一切正常,也有一些sql会比mysql查询速度明显快,但是如我所说的这类的sql对比mysql就没有明显的优势