为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
【概述】 场景 + 问题概述
【背景】 做过哪些操作
无操作
【现象】 业务和数据库现象
【问题】 当前遇到的问题
GC 无法进行, 并且tidb-server 一直做scan tikv
【业务影响】
下掉异常的tidb-server，业务暂时无影响
【TiDB 版本】
4.0.6
【应用软件及版本】
【附件】 相关日志及配置信息
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
上面 gc worker 的 safe point 应该是正常推进的，对应的也是今天的时间，expired_at 这个值显示是正常的； tidb 上的扫描跟 gc 是两个问题，需要查一下 processlist 或 dashboard slow query 看看是什么 SQL
目前慢查和 processlit 都是正常 按照主键更新的SQL语句，并没有很大的慢查
这个expired_at 时间是负值也正常吗 ？
另外3台tidb server，有两台是如图中火焰图的情况，另外一台正常访问
gc_worker 这个设定是不会过期，所以用负值表示；tidb 从火焰图看应该是有一些对大表在请求 tiflash 相关的副本，这个集群有没有 tiflash 节点，对 tiflash 表做过什么操作
查询的时候tiflash列查，cbo自动选择查tiflash还是tikv
最近有没有执行过批量的 truncate/drop table 等 DDL，看一下 admin show ddl jobs
从上面 ddl 截图看，dropped ddl job 数量比较多，根据这里 https://github.com/pingcap/tidb/pull/17969 的描述，如果有大量的 droped/truncated DDL 历史任务，并且 gc life time 设置比较长，tiflash 调用 tidb API 接口 /tiflash/replica 会比较耗时，负载也比较高
调大 [flash.flash_cluster]update_rule_interval 参数（默认 5s）可以降低 tiflash 调用 API 接口的频率，从而降低以上场景下的 tidb 负载
感谢指导
我试试，调整到300s
调整这个频率，但是调用接口的时候还是会导致tidb负载增大呢？有没有这块flash调用tidb 影响的性能指标？
上面 ticdc 的状态正常吗，看那个 gc_safe_point 一直没有推进，查一下 select * from mysql.tidb 的 safe point
tikv_gc_safe_point 还是2个多月前 
TiCDC stop 的话就删掉吧，要不然处于这个状态的 changefeed 会阻挡 GC 推进
https://docs.pingcap.com/zh/tidb/stable/manage-ticdc#删除同步任务
删除 TiCDC 任务后，需要特别注意控制下 GC 的流量，毕竟 GC 掉两个多月的历史数据，gc 的数据量太大可能会对集群负载产生较大的影响
可以先调大 gc_life_time，让集群先 gc 少量数据观察下
比如先 update mysql.tidb set variable_value=‘1608h’ where variable_name=‘tikv_gc_life_time’，这样等 gc 掉大概一周的历史数据，期间观察集群的负载，同时 update mysql.tidb set VARIABLE_VALUE=‘1h’ where VARIABLE_NAME=‘tikv_gc_run_interval’;
等 gc_safe_point 推进到 8.9-8.10 左右再调整 gc_life_time，继续 gc 下一个时间范围的数据
gc 期间如果流量过大，需要设置下 gc 流控，这个可以在线调整，也可以提前设置比如设置为 1MB 或 512K
https://docs.pingcap.com/zh/tidb/v4.0/garbage-collection-configuration#流控
