一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题
【TiDB 使用环境】生产环境
【TiDB 版本】v7.1.3
【部署方式】机器部署
【操作系统/CPU 架构/芯片详情】centos7
【机器部署详情】32/128G/4T
【集群数据量】30T
【集群节点数】
【问题复现路径】几张大表，数据量在20-30亿级别，最近清理掉一半的数据
【遇到的问题：问题现象及影响】
数据清理完之后，过了大概一周发现这些表的数据查询超时，查询方法为不加任何条件： select * from TB1 limit 1
查看执行计划发现是全表扫描， 所以执行时间非常长， 请问要如何解决？
已经对表手动分析过，健康度100
手动compact了吗
手动compact好像针对tiflash的，我这边暂时未用tiflash
删了数据，这是做了标记。数据并未删除。等待gc周期。
region大小问题，未及时合并。即便手工analyze，仍可能误判执行计划。如果等不及 可试下 索引提示（Index Hint） 规避。
数据应该还没有真正清理，等待GC
数据删除已超过一周，GC时间是3个小时，你这里说的GC是自动compression吗？
数据没有清理完，手动更新一下，然后验证呢？
手动做一下分析,然后看看执行计划有什么变化吗
explain analyze实际看一下，扫描了多少key。确定gc是否已经执行。
感觉应该是region未合并造成的，可以执行命令查看下目前表的region数，或者到监控面板查看是否有大量的empty-region
SELECT COUNT(*) FROM information_schema.tidb_regions WHERE table_name = ‘TB1’;
统计信息搜集过吗
参照这个吧。
博客 - MVCC导致limit 1执行慢测试 | TiDB 社区
cop_num也多，可能空region比较多？批量删除数据后，region没有merge？
可能后台还没有自动合并完呢
但是它这个过了一周了会还没有合并完吗
30TB 级别用 DELETE 清理大量数据本身就是高风险操作。建议后续改为按时间范围分区 + DROP PARTITION——分区删除是 DDL 操作，直接物理清理，不产生 MVCC tombstone，不会出现这个问题。另外提一句，30TB 集群这种规模，GC/Compaction/Region 健康度的监控靠手工 SHOW 命令确实吃力。平凯数据库企业版的 TEM 运维平台内置了 GC 推进监控、Region 空洞检测、Compaction 积压告警这类面板——类似问题在 Grafana 上几分钟就能定位，不用一个个命令排查。有需要可以了解一下。
这个情况是数据其实未完全清理
Dashboard是否看过
执行计划的文本可以发出来看看
收集一下统计信息看看
