【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】v 6.5
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
limit 1 查询耗时慢
【资源配置】
【附件：截图/日志/监控】
执行计划：
并发参数：
并发参数：
select * from mysql.tidb看下gc推进了没有，太多没有gc掉的数据了，还是你刚刚对表进行了大批量的删除操作？
从 delete_skipped_count的数据看，gc还是正常的，gc默认是10分钟
看下tikv-detail GC相关的监控，GC正常的话，可以按如下处理
1、 业务低峰时每个tikv做下compact:
tikv-ctl --host 10.172.65.156:20161 compact -c write和default -d kv --bottommost force
2、表重建
3、升级最新补丁版本
1 个赞
第一个 这个compact ，理解为tikv层进行数据压缩，但是这个是因为tikv的什么原因呢，能够展开说一下吗？
GC再tikv层是清理掉了，但对于rocksdb实际只是打了删除标，等到compact时才将这些打标的处理掉。
删除应该还插入很多数据吧，删除时候regions明显变多
explain analyze 执行的是比较真实的执行计划。
这个表有主键么？感觉应该秒返回才对。
tidb里delete也是 insert一条delete 标记的数据 ，这是tidb层的
id是自增id，也是主键
本地试了一下，感觉是二楼说的那种情况，我这边的扫描的key很少
tikv_task:{time:1ms, loops:1}, scan_detail: {total_process_keys: 1, total_process_keys_size: 299, total_keys: 2, get_snapshot_time: 71.9µs, rocksdb: {key_skipped_count: 1, block: {cache_hit_count: 14}}}
compact主要效果是什么，相对数据库本身的优势是什么
1 个赞
谢谢，学习了，官方文档关于这个就写了用法，具体内容没说清楚
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。