【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
流量图热点表 已经在09:54被drop掉了，结果还是一直显示有
(user:tidbdba time: 09:54)[db: yixintui_operate]drop table yixintui_operate_arch.ad_manage_log_20230411 ;
Query OK, 0 rows affected (0.52 sec)
通过pd 能查到region存在，但是查不到表名
怀疑是不是 gc lifetime 影响的
Drop/Truncate Table ，Drop Index 会先把 Ranges 写进 TiDB 系统表（mysql.gc_delete_range），TiDB 的 GC worker 定期查看是否过了 Safepoint，然后拿出这些 Ranges，并发的给 TiKV 去删除 sst 文件，并发数和 concurrency 无关，而是直接发给各个 TiKV。删除是直接删除，不需要等 compact 。完成 Delete Ranges 后，会记录在 TiDB 系统表 mysql.gc_delete_range_done，表中的内容过 24 小时后会清除:
mysql> select * from gc_delete_range_done;
看一下是否被gc掉
gc lifetime 设置的16h， 所以还没到时间。 不知道哪里在频繁的读造成热点。或者是你说的TiDB 的 GC worker 定期查看是否过了 Safepoint，但是这个频率也太高了
是这样的忽略 等数据更新就好了
我看文档有用SQL 查询出来 WRITTEN_BYTES 最大的前 3 个 Region 所在的 TiKV 地址SELECT
address,
tikv.address,
region.region_id
FROM
TIKV_STORE_STATUS tikv,
TIKV_REGION_PEERS peer,
(SELECT * FROM tikv_region_status ORDER BY written_bytes DESC LIMIT 3) region
WHERE
region.region_id = peer.region_id
AND peer.is_leader = 1
AND peer.store_id = tikv.store_id; 是不是很具这几张表也可以查询出来读热点
gc到期后，热点就没有了。
为什么drop 之后的表会有热点，会不会对集群性能有影响
可以看下 tidb_gc_run_interval这个参数的设置
这个变量用于指定垃圾回收 (GC) 运行的时间间隔，可以该稍微大一点
还是默认值， 我改大点，再观察下
hello，想了解下你们 tidb 的版本是啥？
另外，可以到 ddl job 上的 ddl 信息
还有就是 热力图 可以提供更完整的截图，要包括 drop 之前的
tidb: 6.1.5
热力图时间久，没有了。
过了gc时间，热力图就正常了
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。
