【TiDB 使用环境】生产环境 /测试/ Poc
【TiDB 版本】8.5.0
【操作系统】openeuler
【部署方式】机器部署（什么机器配置、什么硬盘）
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
SQL语句里面包含了几个exists查询其它表，在mysql时这个语句在1秒左右内能查询完成，但是迁移到TIDB后需要2分多时间，看了Dashboard的执行时间，发现是coprocessor执行耗时基本占了全部问题，是需要修改什么配置吗？
语句中的表数据量都不大，几万条的数量。
得看下执行计划
按数据量来计算时间
看看具体的SQL，索引选不对可能也会这样
select t1.*,
(select count(1) from t2 where t1.id = t2.aid) as a,
(select count(1) from t2 where t1.id = t2.aid) as b,
(select count(1) from t2 where t1.id = t2.aid) as c
from t1
where t1.delete = 0
and exists(select 1 from t2 where t1.id = t2.aid)
order by
a desc,
t1.g, t1.f
limit 10
随便写了一个类似的SQL
刚刚测试了下，我的SQL在select有对其他表进行查询统计数量（假设是a、b、c、d四个统计字段），然后在order by里对某一个查询结果字段 a 进行了排序，我把这个字段a排序去掉只留对form 里的表字段进行排序并limit，速度就正常，一旦加上了字段a 的排序，或者是去掉limit，速度就很慢。
t1表的数据量2万条，t2表的数据量20万条，t2表有aid字段索引。
首先这个SQL应该和实际相差挺大的吧，本身看着也挺怪的。
其次有 limit 自然会比不 limit 要快，特别是数据量大的时候；至于排序，你的排序字段是什么类型的？再看有没有索引？这也会关系到排序的速度好坏
要看执行计划的，是不是比mysql少了索引
把表结构拿出来。执行计划也贴出来
使用EXPLAIN ANALYZE仔细查看执行计划，重点关注索引使用和统计信息是否准确。
要不试一下trace详细过程,看看哪些地方用了多少时间.