问题现象
在实际应用场景中，由于表上分区数量过多，可能出现参与者数量过多的事务（参与者数量超过 100，部分场景有 4000 以上）。 当参与者数量过多后，将导致：
事务提交阶段悬挂，进而影响系统可用性（clog 日志文件回收）。
网络带宽消耗加剧。
CPU 消耗加剧。
关键诊断信息
触发条件
用户表上分区数量过多。
问题原因
主要原因是用户表上分区数量过多，SQL 执行过程中将参与者信息反馈给事务层，进而导致参与者数量过多。
目前 OceanBase 数据库采用了两阶段提交逻辑保证分布式事务提交的原子性。而当参与者数量过多的时候，会导致：
参与者列表过大。
消息数量过多。
参与者列表过大和消息数量过多将直接导致网络带宽消耗加剧，并且由于协调者处理能力受限，将存在 CPU 消耗加剧的情况。并且由于内部重试机制的局限性，会存在事务悬挂的情况。
问题的风险及影响
由于网络和 CPU 消耗加剧，将直接影响系统性能。
由于悬挂事务的引入，将影响 clog 日志的回收，进而影响系统的可用性。
影响租户
影响 OceanBase 数据库中的 Oracle 租户和 MySQL 租户，对于 SYS 租户无影响。
影响的版本
OceanBase 数据库企业版 V3.1.2 GA（oceanbase-3.1.2-20210618150922）及之后版本、V3.2.3 GA（oceanbase-3.2.3.0-20220419）及之后版本。
解决方法
解决方法一：
升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V3.1.2 BP10 Hotfix1（oceanbase-3.1.2-110010012022102515）、V3.1.2 BP10 Hotfix2（oceanbase-3.1.2-110020012022110920）、V3.1.2 BP10 Hotfix3（oceanbase-3.1.2-110030012022112109）、V3.1.2 BP10 Hotfix4（oceanbase-3.1.2-110040012022120115）、V3.1.2 BP10 Hotfix5（oceanbase-3.1.2-110050022022120810）、V3.1.2 BP11（oceanbase-3.1.2-111000052023010412）、V3.2.3 BP5（oceanbase-3.2.3.2-105000062022090916）。
解决方法二：
需要避免参与者数量过多的事务，因此增加告警日志，协助业务避免该类事务。
调大内部两阶段提交的重试机制中超时时间间隔，避免生产环境不可恢复的问题。
增加统计信息，协助分析业务代码。
