Key is locked (will clean up),meta_lock指标一直报警。

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
生产环境 or 测试环境 or POC
【概述】 场景 + 问题概述
tidb集群后台写入非常频繁。业务全量上线后导致读写冲突的告警非常多。
tikv后台日志
image

tidb后台日志:

Grafana 监控

【现象】 业务和数据库现象
业务数据库性能抖动,并发上来后出现卡顿缓慢。业务操作数据库写比较频繁。
【问题】 当前遇到的问题
集群查询数据变慢,写入有延迟。
【业务影响】

【TiDB 版本】
v5.4

【附件】 相关日志及监控(https://metricstool.pingcap.com/)

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

事务冲突,先看下慢SQL。
提问时多写写问题描述

事务冲突太频繁了

这个冲突可以避免么? 从业务场景上优化一下?

看下日志里冲突的key是相同的吗? autocommit下悲观事务默认也会先以乐观模式提交,试试会话非autocommit

不相同的

用的是 乐观锁 吧?
读写冲突原理 : https://docs.pingcap.com/zh/tidb/stable/troubleshoot-lock-conflicts#读写冲突
解决方法步骤:首先,在 tidb.log 中搜索 txnLockFast 相关字样,获取事务崩溃 startTs;其次,在 tidb_slow_query.log 中基于 startTs 反追对应事务内的 SQL ,判断出哪个事务导致的读写冲突。最后交给业务去改,避免这种情况发生。

你们是把tidb当业务库来用吗?怎么会又这么频繁的冲突

目前就是承担了业务库