LockKeys_time占用时长大的sql该怎么优化

[Miracle]

【概述】 场景 + 问题概述

sql语句是一个很简单的update， id是主键，表里的数据大概9w，这个update3~9s都出现过。
update t1 set col_1='a', col_2='b', col_3='c' where id=123;
我看了slow_query这张表，sql耗时基本都是LockKeys_time。

【问题】 当前遇到的问题
1.lockkeys_time的含义是什么？我在官方文档里没找到，感觉像是锁等待？
2.这种sql我该怎么优化？

【TiDB 版本】
V-5.4.0

【执行计划】
id task estRows operator info actRows execution info memory disk

Update_9        root    0       N/A                                         0       time:4.61s, loops:2, , lock_keys: {time:844.1µs, region:2, keys:2, lock_rpc:784.261µs, rpc_count:2, retry_count:1}  0 Bytes N/A

└─Point_Get_1   root    1       table:xxx, index:PRIMARY(id), lock  1       time:4.61s, loops:3, Get:{num_rpc:2, total_time:644.2µs}                                                            N/A     N/A

[Min_Chen (Make the world more reliable)]

您好，从给到的执行计划上看到是 point_get 比较耗时，请查看监控判断 tikv 或网络是否有问题。

[xfworld (魔幻之翼)]

1. lockkeys_time 就里面为字面的意思就好了，从数据库获取数据后，对该数据进行加锁

2. select col_1,col_2,col_3 from t1 where id = 123; 需要执行多久拿到结果？

[alfred]

LockKeys_time 花费时间长应该锁等待造成的，当LockKeys_time较长时可以查询下锁等待的情况，锁等待是业务逻辑、程序调度等导致的数据操作冲突，数据库层面可以查找相关冲突的事务进行优化。

[Miracle]

单独尝试select或者update都挺快的，0.5s左右，应该是偶然现象。
慢的这个sql是业务代码里执行的。