单条insert语句耗时超过2s频现，请问怎么定位问题？

🪐 TiDB 技术问题
1

作为实时数仓使用的，对应的表是用于存储类Debezium json增量日志的。
表为聚簇索引，主键使用默认uuid()赋值

time:3.48s, loops:2, prepare: 105.4µs, insert:137.7µs, lock_keys: {time:3.48s, region:2, keys:2, slowest_rpc: {total: 2.034s, region_id: 100470545, store: 192.168.0.111:20160, time_detail: {tikv_wall_time: 52.7ms}, scan_detail: {get_snapshot_time: 25.8µs, rocksdb: {block: {cache_hit_count: 6}}}, }, lock_rpc:3.477822517s, rpc_count:2}

INSERT INTO
  sync_table_log_xx (
    table_name,
    ds_code,
    lsn,
    rsn,
    log_time,
    source_time,
    body (单行数据变更对应的Debezium json日志)
  )
VALUES
  (?, ?, ?, ?, ?, ?, ?)
2

body 字段拿掉试下呢

3

body字符长度5000

4

看lock_rpc耗时长，默认uuid主键无锁冲突。是因为网络导致的吗，怎么具体定位？

5

大日志，2S应该正常吧

6

SELECT key, COUNT(*) AS count
FROM information_schema.data_lock_waits
GROUP BY key
ORDER BY count DESC;
看下

7

空的

主键是用uuid函数生成的
id varchar(50) COLLATE utf8mb4_general_ci NOT NULL DEFAULT (uuid()),

8

TiDB与TiKV节点（192.168.0.111:20160）之间的网络有问题吗，或者你这个插入并发会很大， TiKV节点负载过高，可以看下tikv的资源使用情况。

9

由于你的表是用于接收 Debezium JSON 日志，通常是高频率小批量写入，如果使用的是默认 UUID 主键（无序），会导致写入热点集中在某个 Region 上。

10

查询表的region分布

SELECT p.STORE_ID,COUNT(1) 
FROM 
	INFORMATION_SCHEMA.TIKV_REGION_STATUS s JOIN 
	INFORMATION_SCHEMA.TIKV_REGION_PEERS p ON s.REGION_ID = p.REGION_ID
WHERE
	s.DB_NAME = "数据库名" AND 
	s.TABLE_NAME = "表名" GROUP BY p.STORE_ID

查询表的leader region分布

SELECT p.STORE_ID,COUNT(1) 
FROM 
	INFORMATION_SCHEMA.TIKV_REGION_STATUS s JOIN 
	INFORMATION_SCHEMA.TIKV_REGION_PEERS p ON s.REGION_ID = p.REGION_ID
WHERE
	s.DB_NAME = "数据库名" AND 
	p.IS_LEADER = 1 AND
	s.TABLE_NAME = "表名" GROUP BY p.STORE_ID
11

日志用es或者Doris撒。tidb不适合实时数仓

12

image
image458×302 4.49 KB

image
image476×291 4.53 KB

13

确实是高频率小批量。会按照表名区分存到不同的sync_table_log_{table}表里。不过是相对的高频率，因为不是2c业务，实际qps是1k。

14

image
image2259×792 286 KB

15

https://docs.pingcap.com/zh/tidb/stable/grafana-tikv-dashboard/#rocksdb---kvraft

  • Compaction pending bytes：等待 compaction 的大小

找一下这个指标，截个图发出来看看。

16

image
image1281×507 86.3 KB

17

总时间约3.48秒（可能包含网络、调度等开销），实际 insert 执行时间约137.7微秒（非常快）， lock_keys 阶段耗时较长（3.48秒），说明锁等待或分布式事务锁延迟是瓶颈，* slowest_rpc 中与 TiKV 节点通信耗时约2秒，可能是网络或TiKV端处理延迟

18

看下锁等待时间 通过TiDB监控面板查看lock_wait_duration指标，确认是否存在大量锁等待。
监控TiKV节点的CPU、磁盘IO、网络带宽使用情况，确认是否存在资源瓶颈。

19

不是很高，除非盘很差，否则可以排除是compaction pending bytes的问题。

20

如果先拿掉这个字段延迟会不会好点，打字段写入本身会有问题