---
title: 分区过多导致事务提交耗时长-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于分区过多导致事务提交耗时长相关的常见问题和使用技巧，帮助您快速解决分区过多导致事务提交耗时长的难题。
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

划线反馈

# 分区过多导致事务提交耗时长

更新时间：2026-06-10 09:51

适用版本： V2.1.x、V2.2.x、V3.1.x、V3.2.x 内容类型：Troubleshoot  

## 适用版本

OceanBase 数据库 V2.x 和 V3.x 版本。

## 问题描述

业务在 100 并发时，事务提交耗时很长（数百毫秒）。

## 问题诊断

1. 观察到 Leader 节点网络流量高，CPU 飙升。

   ![1](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/transaction-management/excessive-partitioning-leads-to-long-transaction-commit-time.png)
 2. 搜索 observer 涉及的事务中表的日志，发现存在 `transaction log sync use too much` 的信息，最长耗时达到 980ms。日志存在大量 `post trans msg error` 报错，持续在 `retry 2pc protocol`。

   ```shell
   [2022-09-07 13:47:28.523024] WARN  [STORAGE.TRANS] post_2pc_request_ (ob_trans_coord_ctx.cpp:3094) [7850][0][Y9C400B9E367C-0005E79A8AFD9F57-0-0] [lt=10] [dc=0] post trans msg error(tmp_ret=-4653, partition_id=[{tid:1101710651083295, partition_id:6, part_cnt:0},{tid:1101710651083295, partition_id:7, part_cnt:0},***,] msg_union.data_.trx_msg_base={tenant_id:1002, trans_id:{hash:18120109983234875456, inc:25809288, addr:"11.xxx.xx.124:40000", t:1662528031779949}, msg_type:260, trans_time:1662628031780238, sender:{tid:1101710651082976, partition_id:0, part_cnt:0}, receiver:{tid:1101710651083295, partition_id:9, part_cnt:0}, trans_param:[access_mode=1, type=3, isolation=1, magic=17361641481138401520, autocommit=0, consistency_type=0(CURRENT_READ), read_snapshot_type=1(STATEMENT_SNAPSHOT), cluster_version=12885033730, is_inner_trans=0], sender_addr:"11.xxx.xx.124:40000", timestamp:1662529622455257})

   ```
 3. 同时，在 observer 日志中可以看到 500 租户出现了请求积压 `req_queue:total_size >0`。

   ```shell
   [2022-09-07 13:47:05.699875] INFO  [SERVER.OMT] ob_multi_tenant.cpp:819 [23311][0][Y0-0000000000000000-0-0] [lt=17] [dc=0] dump tenant info(tenant={id:1002, compat_mode:0, unit_min_cpu:"8.000000000000000000e+00", unit_max_cpu:"1.200000000000000000e+01", slice:"0.000000000000000000e+00", slice_remain:"0.000000000000000000e+00", token_cnt:42, sug_token_cnt:42, ass_token_cnt:42, lq_tokens:4, used_lq_tokens:0, stopped:false, idle_us:4395011, recv_hp_rpc_cnt:935154, recv_np_rpc_cnt:10925, recv_lp_rpc_cnt:0, recv_mysql_ps_close_cnt:0, recv_mysql_cnt:7780, recv_task_cnt:219, recv_large_req_cnt:1911, tt_large_quries:45177, pop_normal_cnt:71139024, actives:42, workers:42, nesting workers:7, lq waiting workers:0, req_queue:total_size=15264 queue[0]=15262 queue[1]=0 queue[2]=0 queue[3]=0 queue[4]=2 queue[5]=0 , large queued:0, reserve queued:0, multi_level_queue:total_size=0 queue[0]=0 queue[1]=0 queue[2]=0 queue[3]=0 queue[4]=0 queue[5]=0 queue[6]=0 queue[7]=0 , recv_level_rpc_cnt:cnt[0]=0 cnt[1]=0 cnt[2]=1 cnt[3]=0 cnt[4]=0 cnt[5]=390 cnt[6]=0 cnt[7]=0 , group_map:null, rpc_stat_info: pcode=0x750:cnt=204851 pcode=0x701:cnt=3894 pcode=0x521:cnt=3498 pcode=0x51f:cnt=316})

   ```
 4. 根据日志信息可以知道，当前事务有大量的参与者。查看对应的 SQL 语句，发现对分区表的更新没有带分区键，从而导致所有的分区均参与到分布式事务中。该分区表按月分区，共有 300 个分区。
 5. 在事务状态表中查看相关事务的统计，可以看到很多事物的参与者有 300 个左右。

   ```shell
   obclient> select count(*) ,trans_id from oceanbase.__all_virtual_trans_stat where partitionlike '%xxxx%' part_trans_action > 2 group by trans_id;

   ```

## 问题原因

业务表分区较多，UPDATE 语句没有指定分区键，从而产生了有较多参与者的分布式事务。而业务的并发又比较高，导致系统内存在大量的分布式事务参与者，而每一个参与者均需要同协调者进行交互，导致网络流量大增，RPC 进程繁忙，clog 同步请求堆积，事务提交缓慢。

## 解决方案

- 为问题表添加全局索引，使 UPDATE 语句通过全局索引来更新单个分区的记录，避免所有分区成为事务参与者。
 - 控制分区的数量，删除提前创建的空分区。

上一篇

[udf 场景下开事务导致事务超限报错 -4013](https://www.oceanbase.com/knowledge-base/oceanbase-database-20000036890)

下一篇

[行锁导致的 DML 卡住的原因及解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002397188) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线