【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】
语句是这样的：
INSERT INTO
xxxxx ON DUPLICATE KEY
UPDATE
xxxxx,
xxxxx,
xxxxx,
xxxxx;
time:391.6µs, loops:1, prepare: 12.4µs, check_insert: {total_time: 379.2µs, mem_insert_time: 48µs, prefetch: 331.2µs, rpc:{BatchGet:{num_rpc:1, total_time:300.3µs}, tikv_wall_time: 106.3µs, scan_detail: {total_keys: 1, get_snapshot_time: 5.97µs, rocksdb: {block: {cache_hit_count: 9}}}}}, commit_txn: {prewrite:365ms, slowest_prewrite_rpc: {total: 0.365s, region_id: 21002, store: 10.95.6.86:20160, tikv_wall_time: 364.7ms, scan_detail: {get_snapshot_time: 9.28µs, rocksdb: {block: {cache_hit_count: 9}}}, write_detail: {store_batch_wait: 358.2ms, propose_send_wait: 0s, persist_log: {total: 6.06ms, write_leader_wait: 74ns, sync_log: 4.6ms, write_memtable: 38.9µs}, commit_log: 6.23ms, apply_batch_wait: 20.7µs, apply: {total:139.7µs, mutex_lock: 0s, write_leader_wait: 0s, write_wal: 20.7µs, write_memtable: 88.6µs}}}, region_num:3, write_keys:3, write_byte:136}
这是什么原因？
事务两阶段提交，慢在第一阶段prewrite，通常就是在进行版本检查、获取写锁冲突耗时较长。
看你给的sql是insert on duplicate key update，按照经验大概率是写写冲突，这个时候你检查一下tidb日志可能会有write conflict 类似关键字。
到官网上或者社区论坛搜搜写冲突怎么处理，会有你想要的处理方式的，一般都是从业务侧解决（比如降低并发，改写sql等）
1 个赞
redgame
(Ti D Ber Pa Amoi Ul)
3
TiKV存储引擎的负载较高，例如磁盘IO繁忙或者存储节点资源不足，都可能导致prewrite_rpc的耗时增加
应该是并发导致的写写冲突，你单独拿一条执行一下看看
有很多这种的
[2023/08/11 05:00:57.223 +00:00] [WARN] [session.go:988] [sql] [conn=650636005754612419] [label=general] [error=“[kv:9007]Write conflict, txnStartTS=443476884114112529, conflictStartTS=443476884114112530, conflictCommitTS=0, key={tableID=226, tableName=xxx.xxx, indexID=2, indexValues={220112010028448478, \u000e+\u000e+\u000e)\u000e*\u000e*\u000e+\u000e)\u000e*\u000e)\u000e)\u000e+\u000e1\u000e-\u000e-\u000e1\u000e-\u000e0\u000e1\u0002\u001b\u000e*\u000e/\u000e2\u000e*\u000e0\u000e,\u000e)\u000e)\u000e.\u000e0\u000e)\u000e)\u000e), }}, originalKey=7480000000000000e25f69800000000000000203830dfeb4f88afade010e2b0e2b0e290e2aff0e2a0e2b0e290e2aff0e290e290e2b0e31ff0e2d0e2d0e310e2dff0e300e31021b0e2aff0e2f0e320e2a0e30ff0e2c0e290e290e2eff0e300e290e290e29ff0000000000000000f7, primary=[]byte(nil), originalPrimaryKey=, reason=Optimistic [try again later]”] [txn=“Txn{state=invalid}”]
你贴的日志说明就是写写冲突了，你在论坛或者官网再搜搜关键字“写写冲突”，会有很多解决方案的，可以根据具体情况来处理问题
