大表删除大量数据之后查询数据超时

TiDBer_AHjy0eKV · 2026 年5 月 11 日 23:10

GC 监控一下

TiDBer_00001 · 2026 年5 月 12 日 01:13

TiDB 是分布式 LSM 架构，你删了 50% 数据只是标记删除，物理空间、Region 分布、实际扫描范围没有真正变小。

TiDBer_00001 · 2026 年5 月 12 日 01:14

这样试下：
执行 ALTER TABLE 表名 COMPACT; 合并数据碎片
低峰执行 ALTER TABLE 表名 RECLAIM DATASPACE; 回收空间
重新 ANALYZE TABLE
执行后查询立即恢复秒级响应。

TiDBer_odwPM8gO · 2026 年5 月 12 日 03:13

应该是删除大量数据后，TiDB 未及时触发 GC/Compaction

TiDBer_1834 · 2026 年5 月 17 日 02:57

调整一下gc，然后更新一下统计信息

xfworld · 2026 年5 月 17 日 03:26

查下这个表相关的 Region 的Key 和 Value 的版本数量，如果和实际 count 数值差不多，说明回收已经完成了。否则，就先想办法 compact 回收掉哪些被标记的 Key。

这个操作会十分影响稳定性，建议在不繁忙的情况下，手动处理。

菩提老祖 · 2026 年5 月 17 日 07:07

第一个可能是 region合并卡主
第两个可能是RocksDB Tombstone堆积
按照优先级操作：

先关 Merge：pd-ctl config set max-merge-region-size 0（立即生效，风险最低）
检查 Region 状态：确认是否有 Region 卡在 pending_merge_state
检查 RocksDB tombstone：如果有大量 tombstone，考虑手动 compaction
确认索引：如果表本身没有合适的索引，limit 1 的确会走全表扫描，但即使如此，如果所有 Region 都正常，limit 1 不应超时

TiDB001 · 2026 年5 月 23 日 15:58

应该是等待GC清理吧

独善其身 · 2026 年5 月 24 日 01:39

region合并中间出现卡顿了吗

TiDBer_1834 · 2026 年6 月 2 日 14:59

删除操作会产生大量的写操作和事务日志，这会增加磁盘I/O和事务日志的写入压力

TiDB001 · 2026 年6 月 3 日 14:40

大量删除操作可能会导致数据碎片化，同时索引也可能变得不完整或失效。这会影响 TiDB 的查询性能。

大唐天子 · 2026 年6 月 7 日 01:39

删除数据实际只是打上删除标记，并非物理清理，需等待 GC 周期完成回收。另外如果 Region 未及时合并、大小异常，即便手动执行 analyze 更新统计信息，优化器仍可能选错执行计划，这种情况可以使用索引提示 (Index Hint) 来强制指定索引，规避问题。

TiDB_001 · 2026 年6 月 7 日 02:01

DELETE 仅做逻辑删除标记，不会立刻物理清理，旧版本数据大量残留；即便 TiDB 自动 GC（默认约 3 小时），海量标记数据也无法短期清理完毕，读取时需要不断跳过删除标记，拖慢查询。

原大表数据分散在海量 Region 中，批量删数后大量 Region 变为空 Region / 小 Region；TiDB 后台 Region Merge 调度缓慢，一周时间仍未完成合并。limit 1 看似只取 1 行，却需要遍历数千个 Region，产生海量 RPC 请求，这是查询超时的最主要原因。

mtmt · 2026 年6 月 8 日 02:33

手动做一下分析看计划