SQL死锁的问题

🪐 TiDB 技术问题 性能调优
,
1

版本 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 ？

2

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

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

3

image

image

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

4

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

5

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

6

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

7

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

1 个赞
8

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