单行记录update锁冲突

【 TiDB 使用环境】生产环境
【 TiDB 版本】5.3.2
【遇到的问题】慢查询中显示有部分update执行时间在50秒左右,但是只是更新一行数据
image


id task estRows operator info actRows execution info memory disk
Update_5 root 0 N/A 0 time:50s, loops:1, , lock_keys: {time:50s, region:1, keys:1, resolve_lock:75.1ms, lock_rpc:49.925128827s, rpc_count:50} 0 Bytes N/A
└─Point_Get_1 root 1 table:wm_do_mail_rela, index:PRIMARY(id), lock 0 time:50s, loops:1, Get:{num_rpc:1, total_time:676.3µs}, scan_detail: {total_process_keys: 1, total_process_keys_size: 44, total_keys: 1, rocksdb: {delete_skipped_count: 0, key_skipped_count: 0, block: {cache_hit_count: 10, read_count: 0, read_byte: 0 Bytes}}} N/A N/A
【排查到确实很多死锁】


【问题现象及影响】
查询资料发现悲观锁冲突解锁时间是50秒。
因为业务原因把隔离级别调整为了rc
但是不太能理解为什么修改单行能互相锁住,正常吗?如何解决?

再贴一个


id task estRows operator info actRows execution info memory disk
Update_5 root 0 N/A 0 time:50s, loops:1, , lock_keys: {time:50s, region:1, keys:1, resolve_lock:9.9ms, backoff: {time: 8.01s, type: [regionMiss]}, lock_rpc:41.967862323s, rpc_count:65} 19.0 KB N/A
└─SelectLock_7 root 0.07 for update 0 1 time:50s, loops:2 N/A N/A
└─IndexLookUp_11 root 0.07 1 time:1.26ms, loops:2, index_task: {total_time: 310.7µs, fetch_handle: 305.9µs, build: 762ns, wait: 4.04µs}, table_task: {total_time: 883.4µs, num: 1, concurrency: 5} 27.0 KB N/A
├─IndexRangeScan_8 cop[tikv] 1.00 table:wm_storage, index:PRIMARY(id), range:[166202640534311911,166202640534311911], keep order:false 1 time:301.3µs, loops:3, cop_task: {num: 1, max: 254.1µs, proc_keys: 1, rpc_num: 1, rpc_time: 237.9µs, copr_cache_hit_ratio: 0.00}, tikv_task:{time:0s, loops:1}, scan_detail: {total_process_keys: 1, total_process_keys_size: 44, total_keys: 1, rocksdb: {delete_skipped_count: 0, key_skipped_count: 0, block: {cache_hit_count: 8, read_count: 0, read_byte: 0 Bytes}}} N/A N/A
└─Selection_10 cop[tikv] 0.07 ge(k3_wms.wm_storage.aqty, 0.0000), ge(k3_wms.wm_storage.iqty, 0.0000), ge(k3_wms.wm_storage.oqty, 1.0000) 1 time:554.1µs, loops:2, cop_task: {num: 1, max: 496µs, proc_keys: 1, rpc_num: 1, rpc_time: 490µs, copr_cache_hit_ratio: 0.00}, tikv_task:{time:0s, loops:1}, scan_detail: {total_process_keys: 1, total_process_keys_size: 282, total_keys: 1, rocksdb: {delete_skipped_count: 0, key_skipped_count: 0, block: {cache_hit_count: 9, read_count: 0, read_byte: 0 Bytes}}} N/A N/A
└─TableRowIDScan_9 cop[tikv] 1.00 table:wm_storage, keep order:false 1 tikv_task:{time:0s, loops:1} N/A N/A

我也遇到这个问题 没啥好的解法

这个就是业务高并发了的自然现象吗?

俺也一样 遇到这个问题,有啥好解法?

老哥,我是来提问的:rofl:

哦哦,我还以为你叫我:see_no_evil:

表结构贴出来看看哇

隔离级别是啥?有没有间隙锁的概念?

根据主键更新,,,,这个和表结构有啥关系

隔离级别因为业务改成了rc

看sql的写法是没有间隙锁的样子啊

MySQL的RC隔离级别是没有间隙锁的,看下日志,看看是否有发现

锁等待导致的阻塞,看下是否存在更新了相同的数据的情况

update语句所在的事务可能有多条语句,导致了事务时间很长。

语句没问题,可能是程序的问题,有些需要异步处理的,程序同步处理,导致事务时间变长。

扔给开发处理。

那就是事务大,拆分应该会好些

我觉得老哥说的是,事务虽然互相锁的是单行,但是其中一个单行修改在大事务里面的话,事务没有结束导致这个一直没解锁是吧

程序上的事务控制不好,是最让人头疼的

是的:rofl::rofl: