为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
5.1
【概述】 场景 + 问题概述
【现象】 业务和数据库现象
【问题】 当前遇到的问题，参考 AskTUG 的 Troubleshooting 读性能慢-慢语句
【统计信息是否最新】
【执行计划内容】
【 SQL 文本、schema 以及 数据分布】
【业务影响】
【TiDB 版本】
【附件】 相关日志及监控（https://metricstool.pingcap.com/)
explain analyze 看下呢，另外表结构是什么样，是否是聚簇索引，表的总行数是多少
2000w 的数据analyze执行了没用
SQL是啥呢？根据执行计划倒推SQL有难度，另外表的结构可以给个例子么?
explain analyze 执行结果，表结构发下
1、数据读取流程
2、根据dashboard里显示的情况，Coprocessor是主要耗时。
排除流程参考：
可能的问题（可根据监控排查）：
1）coprocessor相关调度参数
2）热点问题
3）不合适的索引 （根据explain 计划 适当的 调整索引）。
出现stats:pseudo就代表该analyze收集统计信息了
explain analyze,不是analyze,主要是看看具体的真实执行计划
先查询了所有符合时间条件的数据然后再做的limit吧
几个tikv的，你这个估计范围太大 全表了 ，，，，
看起来是扫描太多了，打码走的索引是business,强制hint下时间字段的索引呢,design_time是什么类型的
都skipped了吧，看key_skipped_cound很多
读取过程中要扫描这些历史版本
gc 时间24小时 业务select查到的数据会紧接着执行删除
每批次删除多少条，110多亿的历史版本，感觉GC没处理这些呢
真的是110亿啊，我都没敢说，我还以为是有单位的。。。
每次删除250个
