没有名字
(没有名字)
2025 年6 月 23 日 03:05
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
(?, ?, ?, ?, ?, ?, ?)
没有名字
(没有名字)
2025 年6 月 23 日 03:19
4
看lock_rpc耗时长,默认uuid主键无锁冲突。是因为网络导致的吗,怎么具体定位?
SELECT key
, COUNT(*) AS count
FROM information_schema.data_lock_waits
GROUP BY key
ORDER BY count
DESC;
看下
没有名字
(没有名字)
2025 年6 月 23 日 07:26
7
空的
主键是用uuid函数生成的
id
varchar(50) COLLATE utf8mb4_general_ci NOT NULL DEFAULT (uuid()),
TiDB与TiKV节点(192.168.0.111:20160)之间的网络有问题吗,或者你这个插入并发会很大, TiKV节点负载过高,可以看下tikv的资源使用情况。
lllzd
(时光旅行者)
2025 年6 月 24 日 02:29
9
由于你的表是用于接收 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
diwing
(Ti D Ber R Qstj35v)
2025 年6 月 24 日 02:43
11
日志用es或者Doris撒。tidb不适合实时数仓
没有名字
(没有名字)
2025 年6 月 24 日 03:25
13
确实是高频率小批量。会按照表名区分存到不同的sync_table_log_{table}表里。不过是相对的高频率,因为不是2c业务,实际qps是1k。
有猫万事足
2025 年6 月 24 日 04:04
15
asmile
(TiDBer 叶明)
2025 年6 月 24 日 05:48
17
总时间约3.48秒(可能包含网络、调度等开销),实际 insert
执行时间约137.7微秒(非常快), lock_keys
阶段耗时较长(3.48秒),说明锁等待或分布式事务锁延迟是瓶颈,* slowest_rpc
中与 TiKV 节点通信耗时约2秒,可能是网络或TiKV端处理延迟
asmile
(TiDBer 叶明)
2025 年6 月 24 日 05:49
18
看下锁等待时间 通过TiDB监控面板查看lock_wait_duration
指标,确认是否存在大量锁等待。
监控TiKV节点的CPU、磁盘IO、网络带宽使用情况,确认是否存在资源瓶颈。
有猫万事足
2025 年6 月 24 日 10:11
19
不是很高,除非盘很差,否则可以排除是compaction pending bytes的问题。
AN_12
(Xiaoqiao)
2025 年6 月 24 日 11:43
20
如果先拿掉这个字段延迟会不会好点,打字段写入本身会有问题