更新同一张表的语句间速度浮动很大的原因

【 TiDB 版本】6.5
对同一张表使用自增主键进行更新时,有时1ms一条,有时10ms一条,期间数据库无其它负载。
1ms时,磁盘IO使用率在10%以下,10ms时相关kv IO使用率增长至90%,请问如何定位造成该现象的原因?

两者的执行计划里面,1ms的那个的point get有一个lock标记10ms的没有

# 1ms
	id            	task	estRows	operator info                                      	actRows	execution info                                                                                                                                                                                                                                                                                  	memory 	disk
	Update_6      	root	0      	N/A                                                	0      	time:504µs, loops:1, lock_keys: {time:384.3µs, region:1, keys:1, slowest_rpc: {total: 0.000s, region_id: 2110830, store: 10.120.33.66:20160, tikv_wall_time: 129.2µs, scan_detail: {get_snapshot_time: 8.78µs, rocksdb: {block: {cache_hit_count: 9}}}, }, lock_rpc:364.748µs, rpc_count:1}	8.85 KB	N/A
	└─Point_Get_10	root	1      	table:cr_customer_position, handle:8033706093, lock	1      	time:405.5µs, loops:2                                                                                                                                                                                                                                                                          	N/A    	N/A

# 10ms
	id           	task	estRows	operator info                                	actRows	execution info                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         	memory 	disk
	Update_4     	root	0      	N/A                                          	0      	time:880.2µs, loops:1, commit_txn: {prewrite:14ms, slowest_prewrite_rpc: {total: 0.014s, region_id: 1911628, store: 10.120.33.66:20160, tikv_wall_time: 13.6ms, scan_detail: {get_snapshot_time: 20.4µs, rocksdb: {block: {cache_hit_count: 15, read_count: 2, read_byte: 4.76 MB, read_time: 4.87ms}}}, write_detail: {store_batch_wait: 142.5µs, propose_send_wait: 0s, persist_log: {total: 2.69ms, write_leader_wait: 72ns, sync_log: 2.61ms, write_memtable: 16.5µs}, commit_log: 2.78ms, apply_batch_wait: 22.3µs, apply: {total:88.1µs, mutex_lock: 0s, write_leader_wait: 0s, write_wal: 22.3µs, write_memtable: 13.3µs}}}, region_num:3, write_keys:5, write_byte:752}	8.86 KB	N/A
	└─Point_Get_6	root	1      	table:cr_customer_position, handle:8032919450	1      	time:721.6µs, loops:2, Get:{num_rpc:1, total_time:688.6µs}                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           	N/A    	N/A

表有自增主键,4个二级索引,50字段,更新中更新4个字段


一个tikv节点吗?是否是各节点的磁盘IO性能不一样,或者数据分区过程中有抖动

有六个kv,io高的是其中3个,大概是region相关的kv?各节点的磁盘容量和性能都是一样的

也不是,所有kv io都会涨,有三个涨得多一些

dashboard页面看一下对应的sql慢在哪?

1ms这个不知为什么似乎统计信息不全,而且很奇怪的是,10ms那个它的actRows=2,但那个字段是主键只可能有一行,累计重试的次数也很多

这个是1ms的

这个是10ms的

看看是不是有写热点了,自增主键容易产生写热点,可以改成auto_random。
看看这个文档有没有帮助https://docs.pingcap.com/zh/tidb/v5.4/troubleshoot-hot-spot-issues#使用-auto_random-处理自增主键热点表

感觉不大像是因为写热点,我更了下问题描述,他俩的执行计划看起来好像都不大一样

10ms:region_num:3, write_keys:5, write_byte:752
1ms:没有看到对应数据,是不是更改前后数据没有发生变化呢?

磁盘性能看着不太高,IO有点变化就影响Prewrite了

这个确实是更到数据了

这个确实,不过为啥同样的操作io会有这么大的区别。。

1ms的时候只是加锁了,10ms的执行计划有 事务 2PC 提交阶段中 prewrite 阶段的耗时14ms

那前者sql的写入的2pc应该是在client commit的时候吧,可为什么后者会造成io增高呢?


IO高峰持续了数分钟,大概率不是这两个更新造成的。

这个是同样的sql一直在跑,大概有600w的数据需要更新

如果更新的是同一张表,监控一下该表在各TiKV节点region的增长数量,看看是否和IO负载有比例关系。

这个IO负载比例确实是有问题集中在三个kv节点上,不过这个不是主要问题,我怀疑即使region均匀分布在了所有kv上,我这个存储的IO也还是会满。现在我把自动提交关掉后,做同样的操作时IO一直都维持在20%以下,commit时也没有发现IO激增,所以现在主要是想知道这个是什么造成的,都存在落盘操作的话,为什么自动提交的落盘的成本要高很多?


https://docs.pingcap.com/zh/tidb/stable/high-concurrency-best-practices#高并发批量插入场景
这个和你的问题有些相似。

为什么自动提交的落盘的成本要高很多?
commit是有成本的。

1 个赞