这边有看到asktug上有相关锁的技术文章讲解了相关悲观锁的原理。
https://asktug.com/t/topic/33550
文章内提到以下内容：
目前业务库使用的是悲观锁。目前业务的一个锁冲突比较严重的表，据反馈，逻辑是
1.delete，根据索引去删除特定的行，
2.insert，插入一条新的行，
3.select，根据索引查询
也看到相关文章说明了，【 tikvlockfast 】：读写冲突，读请求碰到还未提交的数据，需要等待其提交之后才能读。
1.那么我这个是属于读写冲突还是写写冲突应该如何判断？
2.“读写冲突比较严重，冲突严重则会大幅降低集群整体的效率”，这点应该如何理解？锁是针对一张表的rowid/唯一索引/region key，但是其他表的查询也会受到影响？
是因为读写冲突/写写冲突导致了TiKV CPU资源消耗导致了查询超时？