mysql.stats_meta 更新很慢 50秒 具体哪个环节时间消耗也看不到

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
tidb5.2.2

【概述】 场景 + 问题概述



【背景】 做过哪些操作

【现象】 业务和数据库现象

【问题】 当前遇到的问题

【业务影响】

【TiDB 版本】
5.2.2
【应用软件及版本】

【附件】 相关日志及配置信息

  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息

监控(https://metricstool.pingcap.com/)

  • TiDB-Overview Grafana监控
  • TiDB Grafana 监控
  • TiKV Grafana 监控
  • PD Grafana 监控
  • 对应模块日志(包含问题前后 1 小时日志)

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

3 个赞

可以看看监控 TiDB 或 TiKV 相关 metric duration 有没有抖动

2 个赞

9:50 前后 好像并没有太大变化


2 个赞

tidb

tikv


2 个赞

试试把 duration 的精度从 0.999 调到 1

2 个赞

哪些图需要调

2 个赞

1 个赞

2 个赞

这里的 50s 应该是悲观锁等锁的耗时,超过了 innodb_lock_wait_timeout 默认的 50s,从执行计划可以看到主要消耗在加锁阶段的 lock_rpc。

2 个赞

怎么优化这种系统表的锁争用等待?

2 个赞

这个现象是一直存在还是从什么时候开始出现的呢

2 个赞

您这个事务很大么?按说不会要这么长时间才对。

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。