SQL死锁的问题

版本 4.0.10

Time: 2021-06-07T21:58:52.573896122+08:00

Txn_start_ts: 425479196896657415

Conn_ID: 12343962

Query_time: 3.570202119

Parse_time: 0.000069923

Compile_time: 0.000146251

Rewrite_time: 0.000018139

Prewrite_time: 3.565945997 Commit_backoff_time: 3.561 Backoff_types: [txnLock txnLock txnLock txnLock txnLock] Resolve_lock_time: 0.001535063 Write_keys: 3 Write_size: 1088 Prewrite_region: 2 Txn_retry: 1

DB: product

Is_internal: false

Digest: 50f2f2d5624ca96ad880d112448c731ff95362563a4ef75dff252b0237c3301b

Num_cop_tasks: 0

Mem_max: 8545

Prepared: false

Plan_from_cache: false

Has_more_results: false

KV_total: 0.007867307

PD_total: 0.000450151

Backoff_total: 3.561

Write_sql_response_total: 0

Succ: true

update table a=m where xx=yy;

这种是因为写写冲突后导致后续的事务backoff事件,从而耗时增加。

1、请问如何能找到跟这个事务写冲突的另外一个事务或者对应的sql语句?
2、写写冲突txnlock后,backoff单次最低100ms,最多3000ms,请问这个需要怎么优化下? try_time=3,每次backoff=500ms ?

在乐观事务下可能会遇到较多的事务冲突,具体的处理可以看看 https://docs.pingcap.com/zh/tidb/stable/troubleshoot-write-conflicts, TiDB 日志中可以过滤下冲突上下文,应该可以找到 start_ts,commit_ts 等信息,然后搜索 slow query 日志找到对应的 sql;或者临时开启 general log 一段时间抓取全量 sql 记录

如果业务冲突比较严重,可以尝试做一些业务上的改造,使用悲观事务,减少冲突重试

image

image

tidb集群设置的是悲观锁模式,但是这里显示的 optimistic模式内部的吗?

是的,我们现在部署新集群,都是建议设置为悲观事务

现在头疼的是 找两个锁冲突的SQL比较麻烦,只能抓全量的SQL来排查业务使用的不合理场景。

这个帖子的解决方案对你有帮助么?

这个可以帮助到,但是还是比较麻烦,如果能像mysql那样查锁信息就比较方便了

1赞

同感,确实查起来比较繁琐