tidb update操作很慢，请求协助

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境
【资源配置】tikv 32C128G

image
image1121×474 24.2 KB

image
image1420×138 6.35 KB

image

2

发一下执行计划呢

1 个赞
3

image
image1535×126 9.33 KB

:grinning:

4

insert的方式也很慢

| id | estRows | estCost | actRows | task | access object | execution info | operator info | memory | disk |
| Insert_1 | 0.00 | 0.00 | 0 | root | | time:9.77s, loops:39, prepare: 2m23.6s, check_insert: {total_time: 6.46s, mem_insert_time: 4.34ms, prefetch: 6.45s, rpc:{BatchGet:{num_rpc:90, total_time:695.3ms},ResolveLock:{num_rpc:50, total_time:414.8ms},txnNotFound_backoff:{num:1, total_time:2ms},txnLockFast_backoff:{num:49, total_time:5.33s}, time_detail: {total_wait_time: 31ns, total_kv_read_wall_time: 37.2ms, tikv_wall_time: 37.8ms}, scan_detail: {total_process_keys: 8, total_process_keys_size: 22256, total_keys: 21, get_snapshot_time: 35.6ms, rocksdb: {key_skipped_count: 9, block: {cache_hit_count: 138}}}}}, commit_txn: {prewrite:783.5µs, region_num:3, write_keys:12, write_byte:21868, txn_retry:1}, lock_keys: {time:1.67ms, region:2, keys:8, slowest_rpc: {total: 0.001s, region_id: 1138422, store: 10.50.124.84:20160, time_detail: {tikv_wall_time: 633.4µs}, scan_detail: {get_snapshot_time: 6.37µs, rocksdb: {key_skipped_count: 68, block: {cache_hit_count: 176}}}, }, lock_rpc:1.625044ms, rpc_count:2} | N/A | 24.1 KB | N/A |

5

什么版本的

6

感觉有锁冲突

7

8.1.1

8

txnLockFast_backoff:{num:49, total_time:5.33s}

9

这个咋解决呀

11

https://docs.pingcap.com/zh/tidb/stable/troubleshoot-lock-conflicts#处理乐观锁冲突问题

12

获取最近发生的死锁错误的信息看看：select * from information_schema.deadlocks; 以及 少数热点 key 造成锁排队：select key, count(*) as count from information_schema.data_lock_waits group by key order by count desc;

13

操作数据的时候，尽量不要怼着同一个 ID 发起并发更新，

insert 不会导致lock 的，一般是 update

14

优化建议：

  1. TiKV 性能问题：从您的执行信息来看，插入操作涉及到与 TiKV 的多次交互，包括 BatchGet 和 ResolveLock 等 RPC 调用。如果这些操作耗时较长，可能是由于 TiKV 性能问题导致的。您可以检查 TiKV 的 CPU 和 IO 资源使用情况，以及磁盘的性能，特别是是否为 SSD，因为 HDD 可能会引入较大的延迟。

  2. 事务处理时间：commit_txn 阶段的 prewrite 时间为 783.5 微秒，虽然看起来不长，但是整体事务重试了一次（txn_retry:1），这可能会导致额外的延迟。您需要检查事务处理过程中是否有锁争用或者 Region 分布不均等问题。

  3. Region 信息过期：如果 Region 信息经常过期，可能会导致额外的 Region 重新加载和调度，从而增加延迟。您可以检查 Region 的调度和分裂合并操作是否频繁，以及是否有必要优化 Region 的大小和分布。

  4. 锁等待：lock_keys 阶段显示有 1.67 毫秒的等待时间，这可能表明存在锁争用。您需要检查是否有大量的写操作在同一时间对同一数据区域进行操作，导致锁等待增加。

  5. 网络延迟：ResolveLock 和 BatchGet 等 RPC 调用的总时间较长，可能与网络延迟有关。您可以检查 TiDB 与 TiKV 之间的网络连接，以及 PD 与 TiKV 之间的网络连接，是否有丢包或者高延迟的情况。

  6. 监控和日志分析：您可以使用 Grafana 监控 TiDB 集群的内存、CPU、网络和 I/O 指标，以分析资源是否充足，以及是否存在瓶颈。

  7. 性能调优：根据 TiDB 社区技术月刊提供的数据加载性能调优方案，您可以尝试调整 TiDB 的配置参数，比如批处理大小、事务大小等，以优化插入性能。