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

作为实时数仓使用的,对应的表是用于存储类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
  (?, ?, ?, ?, ?, ?, ?)

body 字段拿掉试下呢

body字符长度5000

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

大日志,2S应该正常吧

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

空的

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

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

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

查询表的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

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


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

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

  • Compaction pending bytes:等待 compaction 的大小

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

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

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

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

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