之前还以为只是单纯的这一个SQL时快时慢，看这duration 应该升高这段时间段都会慢吧，tikv配置什么样，检查下这期间的tikv资源消耗 和tikv-detail监控
1 个赞
3点多应该还是有慢SQL，建议排查慢SQL
看看sql能不能优化一下
嗯，注意时间范围，开始时间可以选3点，结束时间选4点30
1 个赞
看看什么sql，这个sql对表数据的影响有多大
不好意思，最近新产品发版比较忙，一直断断续续在排查。 发现有的 sql 即使非常简单，也特别慢，所以怀疑的方向从慢速 sql ，有没有可能是事务锁造成的。麻烦请教问下， 在 v5.0.4 版本中，如何看到锁记录呢？
参考这个看看
队列中有烂SQL占用资源了，偶发执行任务排队，你看看前边在执行什么吧
这种情况。晚上定时跑批量任务。基本都是资源问题导致的。你可以看下qps ，tps是不是都有突增的情况。然后再结合cpu，内存，io资源消耗情况。基本就可以确定了。如果不想扩容，就把任务时间拉长。比如之前5分钟的任务，拉成到10分钟，半小时。
你的问题，基本应该就是每天凌晨3点到4点半左右应该有大批量的报表类sql查询导致集群整体资源紧张导致的，我看你没有tiflash节点，我的建议是，你先部署一个tiflash节点，然后把3点左右执行的大报表sql找出来，对其中大表都配置上tiflash副本，先把对生产的tikv的压力降低下来，不要影响正常业务再说。
1 个赞
读热点吧， 看下kv 的cpu/磁盘io等数据吧
感谢各位的协助排查。最终原因找到了。
由于我们程序服务是分布式服务，有一些计划任务会在所有服务节点同时执行相同的语句，造成锁问题。目前已经调整重新更新程序，进行观察
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。