--- title: "分布式事务 - OceanBase 数据库 V4.2.3 | OceanBase 文档中心" description: 分布式事务 不同类型的事务提交耗时不同，性能调优尽量降低跨机分布式事务的比例。事务模型可以从以下几个方面入手： 业务整体逻辑。 细化到具体的事务。 了解多表、单表事务的比例以及各类 SQL 的执行频率。 事务类型统计 SQL 的执行计划分为四种：Local 、Remote 、Distribute 和 Uncertai… --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库分布式版 - V 4.2.3 # 分布式事务 更新时间：2024-04-24 14:53:01 [编辑](https://github.com/oceanbase/oceanbase-doc/edit/V4.2.3/zh-CN/700.reference/1000.performance-tuning-guide/400.business-model-tuning/300.distributed-transactions.md) 不同类型的事务提交耗时不同，性能调优尽量降低跨机分布式事务的比例。事务模型可以从以下几个方面入手： - 业务整体逻辑。 - 细化到具体的事务。 - 了解多表、单表事务的比例以及各类 SQL 的执行频率。 ## 事务类型统计 SQL 的执行计划分为四种：Local 、Remote 、Distribute 和 Uncertain。其中 Local 表示当前语句所涉及的分区 Leader 与 Session 所在的机器相同；Remote表示当前语句所涉及的分区 Leader 与 Session 所在的机器不同；Distribute 和 Uncertain 计划不能确定 Leader 和 Session 的关系，可能在同一个机器，也可能跨多机。 对于事务的性能而言，优先使用单机事务，其次才是分布式事务；根据执行计划的类型统计信息，可以大致估算出分布式事务的比例，进而为调优提供数据支持。相关 SQL 如下： ```sql MySQL [oceanbase]> select plan_type, count(1) from gv$ob_sql_audit where request_time > time_to_usec('2021-08-24 18:00:00') group by plan_type; +-----------+----------+ | plan_type | count(1) | +-----------+----------+ | 1 | 17119 | | 0 | 9614 | | 3 | 4400 | | 2 | 23429 | +-----------+----------+ 4 rows in set ``` 其中，`plan_type` = 1、2、3 分别表示 Local 、Remote 、Distribute 执行计划。一般来讲，0 代表无 plan 的 SQL 语句，比如：set autocommit=0/1，commit 等。 ## 非 local 计划分析 非 Local 计划的请求（ plan_type = 0 除外），大概率会导致事务跨机，相对于单机事务，性能会有一定的影响。可按照如下几种情况进行检查： 1. Primary Zone 为单 Zone & 单 Unit。 2. Primary Zone 为单 Zone & 多 Unit。 3. Primary Zone 为 RANDOM。 ### Primary Zone 为单 Zone & 单 Unit 单 Unit 部署的场景如果出现 Remote、Uncertain 计划，是不符合预期的，原因大概有几种： 1. 直连了该租户的 Follower。可根据执行计划的类型统计信息确认。 2. 应用连接了 OBProxy，但事务的第一条 SQL 无法被 OBProxy 进行正确的转发，导致 Session 和事务所涉及的分区 Leader 跨机。此时需要去检查本集群所有 OBProxy 的日志，关键日志信息如下： ```sql fail to caculate partition id, just use tenant server ``` 3. 部分分区刚刚切主，OBServer 或者 OBPoxy 维护的 Location Cache 尚未刷新到最新。 如果是情况 1，需要让应用改成连接 OBProxy；如果是情况 2，说明当前 SQL 较为复杂，OBProxy 在 Parser 过程中无法计算出需要访问的分区，因此随机做了发送。此时需要对 SQL 写法进行调整，带上分区键；如果是情况 3，则不需要处理。 ### Primary Zone 为单 Zone & 多 Unit 该场景下，同 Zone 的 OBServer 会自动进行分区负载均衡，事务跨机大概率是可能的。为了避免跨机事务，结合事务内语句执行情况，进行 Table Group 划分，尽量保证事务单机执行。 Table Group 的用法如下所示： ```sql --非分区场景 create tablegroup tg1; create table t1 (id1 int, id2 int) tablegroup tg1; create table t2 (id1 int, id2 int) tablegroup tg1; --HASH 分区（MySQL 模式） create tablegroup tg2 partition by hash partitions 2; create table pg_trans_test2_1(id1 int, id2 int) tablegroup tg2 partition by hash(id1 % 2) partitions 2; create table pg_trans_test2_2(id1 int, id2 int) tablegroup tg2 partition by hash(id1 % 2) partitions 2; --HASH 分区（Oracle 模式） create tablegroup tg2 partition by hash partitions 2; create table pg_trans_test2_1(id1 int, id2 int) tablegroup tg2 partition by hash(id1) partitions 2; create table pg_trans_test2_2(id1 int, id2 int) tablegroup tg2 partition by hash(id1) partitions 2; --RANGE 分区（MySQL 模式） create tablegroup tg3 partition by range columns 1 ( partition p0 values less than (10), partition p1 values less than(20)); create table pg_trans_test3_1(id1 int, id2 int) tablegroup tg3 partition by range columns(id1) (partition p0 values less than (10), partition p1 values less than(20)); create table pg_trans_test3_2(id1 int, id2 int) tablegroup tg3 partition by range columns(id1) (partition p0 values less than (10), partition p1 values less than(20)); --RANGE 分区（Oracle 模式） create tablegroup tg3 partition by range columns 1 (partition p0 values less than (10), partition p1 values less than(20)); create table pg_trans_test3_1(id1 int, id2 int) tablegroup tg3 partition by range (id1) (partition p0 values less than (10), partition p1 values less than(20)); create table pg_trans_test3_2(id1 int, id2 int) tablegroup tg3 partition by range (id1) (partition p0 values less than (10), partition p1 values less than(20)); --LIST 分区 (MySQL 模式) create tablegroup tg4 partition by list columns 1 ( partition p0 values in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10), partition p1 values in (11, 12, 13, 14, 15, 16, 17, 18, 19, 20) ); create table pg_trans_test4_1(id1 int, id2 int) tablegroup tg4 partition by list columns(id1) ( partition p0 values in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10), partition p1 values in (11, 12, 13, 14, 15, 16, 17, 18, 19, 20) ); create table pg_trans_test4_2(id1 int, id2 int) tablegroup tg4 partition by list columns(id1) ( partition p0 values in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10), partition p1 values in (11, 12, 13, 14, 15, 16, 17, 18, 19, 20) ); --LIST 分区 (Oracle 模式) create tablegroup tg4 partition by list columns 1 ( partition p0 values (1, 2, 3, 4, 5, 6, 7, 8, 9, 10), partition p1 values (11, 12, 13, 14, 15, 16, 17, 18, 19, 20) ); create table pg_trans_test4_1(id1 int, id2 int) tablegroup tg4 partition by list(id1) ( partition p0 values (1, 2, 3, 4, 5, 6, 7, 8, 9, 10), partition p1 values (11, 12, 13, 14, 15, 16, 17, 18, 19, 20) ); create table pg_trans_test4_2(id1 int, id2 int) tablegroup tg4 partition by list(id1) ( partition p0 values (1, 2, 3, 4, 5, 6, 7, 8, 9, 10), partition p1 values (11, 12, 13, 14, 15, 16, 17, 18, 19, 20) ); ``` ### Primary Zone 为 RANDOM RANDOM 部署，该租户的表 Leader 随机打散，分布式跨机事务同样是大概率的。 ## 事务提交优化方案 ### 单表 & 多表单机事务 OceanBase 数据库 V4.0 版本由于做了单日志流架构的调整，只要事务涉及的日志流 Leader 在同一个机器，默认会走单日志流事务。这种事务模型性能最高，因此不需要任何配置项的调整. ### 跨机事务 主要解决如下两个问题： 1. 尽可能利用多机能力。 2. OBServer 流量负载均衡。 具体手段： - 为了避免跨机事务，结合事务内语句执行情况，进行 Table Group 划分，尽量保证事务单机执行。具体请参见 **primary zone 为单 zone & 多unit**。 - 对于批量导入的场景，尽可能利用 PDML 并行执行的能力（ 3.2 及之后的版本）。 - 根据负载情况调整网络线程数量（ `net_thread_count` )，该配置项默认为 0，进程启动之后，根据当前机器 CPU 核数，自适应计算出本机需要的数量，公式如下：`min( 6, cpu_core/8 )`；根据实际的情况，手动调整预期值，进程重启生效。 ### 注意事项 - V2.2.x 及之前的版本，不允许打开一阶段提交优化。 - V3.2.x 及之前的版本，不建议生产环境用 Partition Group 优化，性能调优可以提高性能。 上一篇 下一篇 ![有帮助](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) 咨询热线