我改改试试
现在就是15
trace 一下这个sql，看下是那个节点比较慢。
GC的问题，之前update/delete的历史版本没有被清除。如果业务允许可以重建该表
1 个赞
这个表上确实有pt-archiver，在删除过期数据
tidb 用pt-archiver 删除数据非常慢，建议安装delete limit的方式删除
1 个赞
好的，改造一下
猜测跟你删数据有关，你查下max，把explain analyze拿出来看下
这个首先要检查下GC问题，先看看看和下面链接里前2个例子能对应不(目前的机制delete 如果不再最底层compact的话释放不了空间)。
针对这个表临时解决有2个方式
1、 前面说的读取重建
2、 对这个表手动compact: 找到表的region然后循环处理
tikv-ctl --host tikv_ip:20160 compact -r XXXX -c write -d kv --bottommost force --threads 4
tikv-ctl --host tikv_ip:20160 compact -r XXXX -c default -d kv --bottommost force --threads 4
删数据，建议使用tidb的非事务DML ,你的版本已经支持了
https://docs.pingcap.com/zh/tidb/stable/non-transactional-dml#非事务-dml-语句
1 个赞
参考一下这个例子，我也是用pt-archiver 跑MySQL快，tidb 非常慢，才试着改写的
date1=
date --date "7 days ago" +"%Y-%m-%d"
delete_db_sql=“delete from mysql_table where create_date_time<‘$date1’ limit 10000”i=0
while ((++i)); do
a=/bin/mysql -uroot -p123456 -A mysql_database -h127.0.0.1 --comments -e "${delete_db_sql}" -vvv|grep "Query OK" |awk '{print $3}'
if(($a<1)); then
break 1
fi
sleep 1
printf “%-4d” $((i))
根据你的执行计划做下猜测，首先因为用到了limit优化，distsql_concurrency自动变为了1，正常来说，只要发一个cop task拿到最小的ID就好了，但是实际情况是，发一个cop task发现这个region全是已删除的数据，然后再发一个，这个region还是已删除的数据，然后一直发了221个cop task才找到一个没删的ID。结合你说你有删数据的操作，应该是删历史数据，ID比较小的，八成就是了。
你看tikv那块算子都是很快的，整体SQL 1分钟就是因为串行的发了很多cop task。
你可以测试查下MAX（ID），explain analyze看下执行计划。
话说你查min（id）意义是啥，看数据清理到那里了？单纯的想要这个快，可以再建立一个ID列索引，或者等老数据GC完，自然就快了
哈哈，就是想查询删除到哪个位置了。
这肯定没法看，可以参考之前的测试
1 个赞
是这个原因造成的吗，如果排除这个删除过期数据的任务执行时间是多长
还没有确认，目前已经停止掉pt-archiver，gc也执行了很多次了，还是有scan_detail: {total_process_keys: 数值依然很大，在想办法能不能把这个表重建一下
嗯，可以先缩小范围测试下。另外我觉得你可以新建一个表，把该表的所有数据复制进去，然后查询新表看下效率如何
你为啥不测试下查max啊
max执行很快，主要是怀疑min扫描到了没有被gc的数据，但是没有证据
只有pt-archiver会用到旧数据，目前已经停了，也看了所有tidb，也没有未提交的事务，就不应该有那么多mvcc的多版本存在，还是scan-detail过多的数据