【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】
【附件：截图/日志/监控】
查看慢查询发现有很多执行50S 的update 还有部分执行时间比较短的update 分别查看执行时间，发现执行50S的SQL 没有显示锁冲突之类的信息
查看慢查询发现有很多执行50S 的update 还有部分执行时间比较短的update 分别查看执行时间，发现执行50S的SQL 没有显示锁冲突之类的信息
- 看下执行计划是否有变动，是否走的索引合理
- 查看下是什么锁，业务上优化下。
https://docs.pingcap.com/zh/tidb/stable/troubleshoot-lock-conflicts
这类都是基于主键进行的更新，主键更新的话正常的话应该很快
嗯 那就排除了执行计划没有走对导致慢的情况。
那就看看锁和集群有没有资源瓶颈或者参数不合理导致资源使用率上不去的情况。
集群的整体使用资源和以前没有太大的区别，不知道这个update 为啥会执行那么长时间
那就看看锁情况呗，你看上文发的那个官网文档 有没有帮助
写写冲突的话不是更新同一条数据的时候才会出现吗？ 但是看哪些50S 的SQL 发现主键更新的值都是不同的
看下这篇对你有没有帮助~
好的 谢谢表妹
我觉得还是锁的问题吧，建议再看一下日志
日志 主要是看哪些内容？我看了下两条SQL 的执行时间，有的有加锁时间有的没有，加锁时长是一直都没有释放吗？
这个排查完成了吗？有什么进展吗 ？
时间都花在上锁上了。肯定是多线程、多并发修改相同的数据了。
要开发修改程序逻辑了，避免同时修改。
应用那边反馈是有多次修改同一条记录的操作，造成后面的脚本等待时间越来越长
1 个赞
已经优化应用的业务逻辑了吧 ？
应用那边说是去查一下