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

[Kongdom]

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

[xfworld (魔幻之翼)]

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

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

[HHHHHHULK (好好学习，天天向上)]

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

[Kongdom]

[Kongdom]

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

[xfworld (魔幻之翼)]

这纯粹是冲突等待了吧…

事务执行的时间有么？

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。

[Kongdom]

没看到有事务执行时间~

[xfworld (魔幻之翼)]

只上锁，不提交阿… 囧

[Kongdom]

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

[xfworld (魔幻之翼)]

隐式的，也会有事务的

[Kongdom]

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

[xfworld (魔幻之翼)]

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

[h5n1]

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

[Kongdom]

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

[xfworld (魔幻之翼)]

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

[Kongdom]

表示没看懂~

[xfworld (魔幻之翼)]

USE information_schema;
DESC slow_query;

图上标记的东东 digest （特征码）[ 还是不能说是 SQL 指纹，不够明确]

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

[Kongdom]

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

[xfworld (魔幻之翼)]

还有个 statements_summary_history

[Kongdom]

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