作者： 连连看 db 原文来源：https://tidb.net/blog/c1abbb6c

一、背景

tidb 版本 5.3，一天 prometheus 的 tikv 突然告警，报警内容包含关键字 meet lock，10 分钟大于 10000 次 meet lock。

二、排查过程

    部门有要求，一旦报警，需要确定报警具体原因，所以开始以下排查

1、首先排查 TiDB 集群访问延迟是否在正常范围

平均访问延迟在 100ms 以下，没有对业务造成影响，但需要关注，排除隐患。

2、查看 tikv 日志

根据官方文档描述：

• primary_lock：锁对应事务的 primary lock。

• lock_version：锁对应事务的 start_ts。

• key：表示被锁的 key。

• lock_ttl: 锁的 TTL。

• txn_size：锁所在事务在其 Region 的 key 数量，指导清锁方式。

找到 primary_lock 频率比较高的 key

cat tikv.log |grep error-response | awk -F “primary_lock:” ‘{print 2}’ | awk -F “ ” ‘{print 1}’ | sort | uniq -c | sort -n24 7480000000000001CA5F6980000000000000010380000000031E2BCA038000000000142F42038005E5362CD7765024 7480000000000001CA5F6980000000000000010380000000031E2BCA038000000000142F42038005E53639926B4824 7480000000000001CA5F6980000000000000010380000000031E2BCA038000000000142F42038005E5363B41404024 7480000000000001CA5F6980000000000000010380000000076F740903800000000014AFE0038005E53639926B4824 7480000000000001CA5F69800000000000000103800000000AC2A32B038000000000134436038005E52CA7AF566825 7480000000000001CA5F6980000000000000010380000000031E2BCA038000000000142F42038005E53639F48C6025 7480000000000001CA5F6980000000000000010380000000031E2BCA038000000000142F42038005E5363A5048C025 7480000000000001CA5F6980000000000000010380000000076F740903800000000014AFE0038005E5363B41404025 7480000000000001CE5F698000000000000001038000000005F3DFF103800000000014B9D1038005E5366AF4C89826 7480000000000001CA5F6980000000000000010380000000076F740903800000000014AFE0038005E5363B93501028 7480000000000001CA5F6980000000000000010380000000031E2BCA038000000000142F42038005E5363B93501028 7480000000000001CA5F6980000000000000010380000000076F740903800000000014AFE0038005E5363A5048C035 7480000000000001CA5F698000000000000001038000000005F3DFF103800000000014B9D1038005E5363C55A9F8

3、prometheus 监控

tidb 官方文档关于锁冲突的描述

4、定位造成读写锁的相关表和 SQL 语句，使用一个小工具叫 mok。

下载地址：https://github.com/disksing/mok

下载好工具后，根据上面 tikv 日志中的被锁的 key，定位是哪张表的主键。

具体看红框内容：

根据上图的表 ID 可以定位到异常表名:ch_im

5、在“sql 语句分析“中找到该时间段的相关 SQL

三、总结

    本次 meta_lock 的报警问题是由于 delete 语句中 in 的数量较多，与生产业务的 insert ignore into 发生锁冲突。虽然没有业务上的影响，但一些小的异常报警，也需要我们提前优化，避免出现更大的问题。

解决方案如下：

1、少量读写冲突（tikvLockFast）或写写冲突（txnLock），集群访问延迟没有明显增加，不需要处理；

     2、根据业务请求分析，优化读、写的慢 SQL：调整插入批量 size 100 -> 10，调整 delete 语句 in 的数量，减少读写冲突概率；

     3、修改事务锁模式，乐观锁→悲观锁；

     4、 关闭异步提交（async commit），tidb 5.0 默认开启异步提交。

  具体可参考：         https://docs.pingcap.com/zh/tidb/stable/system-variables#tidb_enable_async_commit-%E4%BB%8E-v50-%E7%89%88%E6%9C%AC%E5%BC%80%E5%A7%8B%E5%BC%95%E5%85%A5

四、优化前后效果

可以看到在使用以上方法后，meta_lock 的问题大幅减少，趋于平稳。