我是每天0-8点执行analyze,另外大表是用定时任务执行analyze

这个tmp目录是系统盘，非SSD吧，这样就需要把fast ddl关掉才行，不然会非常慢

看你是7.1.0的版本，试下关闭这个参数，看看有没有效果 https://docs.pingcap.com/zh/tidb/stable/garbage-collection-configuration/#gc-in-compaction-filter-机制

你的tikv是混布的吧，一台机器几个tikv,一共多少个kv,当前单个kv的数据量多少，region总量多少，如果很多的话也是有可能的

十分钟应该是gc的时间，可以看下与gc时间是否对应

我后续搭个环境试试

这个在测试环境没问题，但是生产是不够的，另外你看下慢sql,是不是很多全表扫的，这些需要处理下，还是tikv的内存配置是什么样的，这都需要看，

不用啊，怎么可能需要定时重启，你看下你的配置，是不是混合部署太多了，配置不太够，另外非常多的慢sql也不是一个线上业务应该有的情况，优化表结构，优化sql语句，该放tiflash的放tiflash,你如果是一堆慢sql，放在任何数据库都不起作用

我找套测试环境试一下吧，看看能不能解决，目前不知道有没有什么未知问题

表大小8000w Original_sql: select * from db . table_name where date >= ? and date <= ? and task_type != ? order by send_ts desc , id desc limit … Bind_sql: SELECT /+ read_from_storage(tiflash[table_name])/ * FROM db.table_name WHERE date >= 20250601 AND date <= 20250630 AND task_type != 4 ORDER BY sen…

其实想着如果这个实验特性仅仅能影响我给资源组的用户且能生效的话，对我当前场景来说还是够用的，升级成本和风险比较高

是啊，但是短时间内指定没法升级了，不是是我操作不对还是有什么骚操作可以让runaway生效，这个帖子我看过，也没看到当前版本的解决办法

如果设置了label,理论上一台物理机宕机不会集群不会挂掉，因为同一个副本不会存放在一台机器上，但是因为单台物理机上放的region数比较多，这就导致了单台物理机挂掉后切换leader的时间很长，这个时间还是会有影响的，具体情况需要测试下业务能不能接受这个

那就很诡异了，从dumpling的日志看导出也就很少的时间，而且看大小kv就几M，结果也是成功的，除了导错链接想不出来别的可能了，github也没有类似bug

mysql -u root -p xxxx -P 4000 -h 127.0.0.1 -e “select count(1) from hdy_user.auth_user_warehouse_menu”,你这样计算下表行数看看，是不是配置了什么代理啥的，代理到测试环境tidb了，导出已经success了，按理说没啥问题

myloader和dumpling应该是不匹配的，grep下sql文件的insert,只有一个insert么，还是有多个

导入是怎么导入的，倒入的石斛有没有遇到报错

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。

登录到机器上，执行sudo dmesg -T,看下有没有对应内存之类的报错