update语句执行时间过长,上锁耗时过长

【 TiDB 使用环境】
【概述】发现系统中有较多慢语句,慢语句都是update语句,且执行时间都用于上锁耗时。
【背景】无
【现象】慢语句
【业务影响】
【TiDB 版本】v4.0.9
【附件】


还有其他的信息,可以放出来么? 比如读取,事务


实际数据有点不一致… 看图的上的描述

悲观事务,有并发,才出现的锁等待吧。可以看看持有锁的事务怎么这么久了还没提交。


只有半个小时内出现这个问题,其余时间就正常了~很奇怪~

这纯粹是冲突等待了吧…

事务执行的时间有么?

commit_txn 执行信息

autocommit=1 的事务中执行写入类型的 DML 语句时,算子的执行信息还会包括事务提交的耗时信息,示例如下:

commit_txn: {prewrite:48.564544ms, wait_prewrite_binlog:47.821579, get_commit_ts:4.277455ms, commit:50.431774ms, region_num:7, write_keys:16, write_byte:536}
  • prewrite :事务 2PC 提交阶段中 prewrite 阶段的耗时。
  • wait_prewrite_binlog: :等待写 prewrite Binlog 的耗时。
  • get_commit_ts :获取事务提交时间戳的耗时。
  • commit :事务 2PC 提交阶段中, commit 阶段的耗时。
  • write_keys :事务中写入 key 的数量。
  • write_byte :事务中写入 key-value 的总字节数量,单位是 byte。

没看到有事务执行时间~

只上锁,不提交阿… 囧

程序里没加事务呀,这个难道不是tidb自己加的锁么?我也好奇为什么没有解锁耗时~

隐式的,也会有事务的

所以能确定这个就是锁等待么?是的话,我就提单修改程序了。

最好能拿到事务执行的部分的时长
这样就很容易判断了

autocommit时,默认先使用乐观模式

这个可以怎么拿呢?这个慢查询是上周六的:thinking:

找个SQL 指纹,拿指纹去查查
都是同一类型的,结果肯定也一样了

:thinking:表示没看懂~

USE information_schema;
DESC slow_query;

图上标记的东东 digest (特征码)[ 还是不能说是 SQL 指纹,不够明确]

然后去 统计记录查一下
statements_summaryinformation_schema 里的一张系统表,它把 SQL 按 SQL digest 和 plan digest 分组,统计每一组的 SQL 信息。
https://docs.pingcap.com/zh/tidb/stable/statement-summary-tables/#statements_summary

1 Like

可惜,这个表statements_summary只有当前的数据,没有历史的数据。

还有个 statements_summary_history

1 Like

也是只有今天的数据:joy:错过了~