为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【TiDB 版本】
v4.0.0
【问题描述】
一个很简单的查询，tidb的速度并不如mysql或者二者速度差不多
explain analyze如下图
要是按照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条
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
按照我的理解TableRowIdScan应该扫描一行这个数据就快了
索引是否包含 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 的执行计划看时走的 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就没有明显的优势
