兜不靠谱
2023 年6 月 27 日 06:11
1
【 TiDB 使用环境】生产环境
另外，tikv此前升级过一次配置，从 32c64g升到48c192g
目标表 340w行，符合上面查询语句的(不加limit)的有54条，analyze table过 前后没有太大变化，其中有个细节，昨天晚上stat healthy 84,到今天早上就49了，业务反馈每天有大约百万的update操作
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】limit10.csv (2.0 KB)limit50.csv (2.0 KB)
Edwin
2023 年6 月 27 日 06:37
2
数据库的GC时间多大，每天有几百万的update? update的数据有没有规律？
1 个赞
兜不靠谱
2023 年6 月 27 日 06:40
3
gc life time 是10 min update是否规律暂时无法考量，业务也只捕捉了一个counter
看你的limit50的执行计划：delete_skipped_count: 21031这个表是不是很多gc数据没有及时清理，查limit50，需要过滤的gc数据太多了
兜不靠谱
2023 年6 月 27 日 06:43
5
有没有方法来印证这个猜测？
Edwin
2023 年6 月 27 日 06:43
6
兜不靠谱:
SELECT workflow_task.id FROM workflow_task WHERE (workflow_task.status = ‘RUNNING’ OR workflow_task.status = ‘CREATED’) AND workflow_task.workflow_id = 720001 ORDER BY workflow_task.priority DESC, workflow_task.created_at limit 50;
带order by 的limit 可以看看 limit 49 及以上的数据，分布是如何的？是不是都是每天update的对象？
兜不靠谱
2023 年6 月 27 日 06:47
7
不加limit 的话 一共就 54 条记录, 感觉还谈不上分布… 但每天update是有的，而且update的行数也和48,49 不会强关联
Edwin
2023 年6 月 27 日 06:48
8
可以看看监控 gc safe point 是不是正常推进的？
1 个赞
你的排序字段去掉试试，我感觉应该是按这个排序的数据导致的，很多对应的数据被删除或者修改了，导致你limit50的时候需要rockdb扫描的数据太多
xfworld
2023 年6 月 27 日 06:49
10
搞个软删除，用单独的字段记录是否被删除就可以了
然后用其他的字段，比如主键和这个记录状态的字段做个联合索引，实现索引打散过滤，这样效率会高很多了（如果单独用这个记录状态作为索引键，会出现热点索引的问题，这个要注意）
或者利用分区，数据的清理通过 truncate 分区，这样也可以提高效率（基本不会影响 limit 的查询效率）
兜不靠谱
2023 年6 月 27 日 06:56
12
去掉排序，秒出，但这个排序+limit 是业务逻辑了~
SHOW config WHERE TYPE=‘tikv’ AND NAME LIKE ‘%enable-compaction-filter%’，看一下这个参数是什么，false的话改成true
兜不靠谱
2023 年6 月 27 日 07:16
14
四个tikv的 enable-compaction-filter 参数都是true
write bytes per sec 10MB 是改大还是改小了？ 我们现在所有tikv 节点 的 io utililty 都 超过95%，我感觉不到最后一步，先不动这个参数
有猫万事足
2023 年6 月 27 日 08:07
15
同一个region top50
top48
时间差异居然如此之大。
另外top50
多少和gc有点关系吧。
兜不靠谱
2023 年6 月 27 日 08:39
16
在 limit 48以下，恒定 秒出。。
有猫万事足
2023 年6 月 27 日 09:18
17
你的gc图真的不太正常。这是我的。差异还是挺明显的。
h5n1
2023 年6 月 28 日 02:08
18
tikv-ctl --host=tikv_ip:port region-properties -r 81758895 和 78757137看看
1 个赞
