【 TiDB 使用环境】生产环境
【 TiDB 版本】6.5.1版本
【复现路径】做过哪些操作出现的问题
truncat表之后写入数据，t_operating_model 这个表, 每天写入不到200万条的数据, 但是健康度下降很快,刚恢复完瞬间就掉到80%多, 数据没有写完就掉到个位数, 然后超时了
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
没遇到过，不知道是不是bug，蹲一个官方
建个新表试试一样不
先不考虑健康度的问题，先该查下超时的错误明细
把这个表truncat之后新建也一样
持续观察下 show stats_meta where table_name like ‘’
表插入更新就会导致健康度降低，看你的描述，频繁清空新增，应该就是正常的吧。
也有类似操作truncate的表，但是健康度不算低。程序应该有日志，先要解决插入失败的问题，应该是什么原因超时了吧
写入和删除频繁的表，可以定时ANALYZE TABLE命令来手动更新表的统计信息。
1、看你描述，表健康度下降看着是预期的结果；
2、看下你们统计信息收集的时间范围，如果是24小时都收集，有可能自动收集还没有完成，等收集完了健康度就上去了；当然，TiDB自动统计信息收集没有想象中的那么高效，我们用的也是V6.5的版本，我们每天也有不少表需要导入T+1数据，导入前都是先truncate，也经常遇到某段时间内统计信息比较低的情况，经和厂商那边沟通，厂商那边建议我们对待这种导入的表再导入完后手动收集一次统计信息。
SQL执行异常？发一下具体报错和执行计划
表清空之后再插入数据，健康度变化快是预期的， 健康度计算公式就是 (1 - modify_count /row_count ) * 100
所以你 modify_count 变化很大的情况下， 健康度也会变化很大
另外你说数据没有写完就超时了是什么意思？ 数据通过什么方式加载到数据库的？
理论上是正常的，实际上这是23年8月就有的代码逻辑，表也只是最近加了几个字段，就变得异常缓慢，插入数据之后查验数据总数不一致
sql执行没有异常，报错就是插入时间超时，最终结果造成数据总数不一致，没有具体的报错信息
数据是通过java代码异步插入到数据库中的，数据没有写完就超时是指写入数据时间远超之前写入时间，且最终写入数据总数不一致
怎么手动收集统计信息呐？
