大事务的处理方式对比

作者：魔幻之翼​

【是否原创】是

TiDB 社区

其他平台首发请附上对应链接

出现 Transaction is too large 的问题，别慌

两种处理方式：

• 增大事务处理的最大限制，提供更多的物理内存用于存放事务数据
• 分批次分割事务，满足功能性的批量处理

方案1：

txn-total-size-limit 事务最大处理的限制，直接调整该参数

​​​txn-entry-size-limit​​ 默认限制了单条 KV entry 不超过 6MB

参考描述：

​​​https://docs.pingcap.com/zh/tidb/stable/migration-tidb-faq/#transaction-too-large-是什么原因怎么解决​​

• 优点：

• 满足整体事务要求
• 能保证一致性和原子性

• 缺点：

• 需要大量的物理内存
• 需要对事务处理的容量做评估

方案2：

• 优点：

• 有限的资源也能完成数据的批量执行
• 不需要对环境和其他的资源做评估

• 缺点：

• 无法满足整体事务的要求
• 不能保证一致性和原子性（对事务进行拆分）
• 需要额外考虑分批后的整体性（某个批次提交失败的场景）

参考开启操作:

SET @@SESSION.tidb_batch_insert = 1;
SET @@SESSION.tidb_batch_delete = 1;
SET @@SESSION.tidb_dml_batch_size = 500;      

以上三个参数依赖下面的属性，这个属性是否开启，直接影响是否能够分批处理

tidb 目前的版本已经支持到大事务功能，分批的方式已经被遗弃，未来大事务越来越成熟，这些参数则不会在被默认启用

enable-batch-dml 属性

https://github.com/pingcap/tidb/blob/8db3a8dc5620d6c48c1a2cadbfcb03488c9787c4/config/config.toml.example#L55      

参考tidb 配置信息

TiDB Configuration.

TiDB server host.

host = “0.0.0.0”

tidb server advertise IP.

advertise-address = “”

TiDB server port.

port = 4000

Registered store name, [tikv, mocktikv, unistore]

store = “unistore”

TiDB storage path.

path = “/tmp/tidb”

The socket file to use for connection.

socket = “/tmp/tidb-{Port}.sock”

Run ddl worker on this tidb-server.

run-ddl = true

Enable batch commit for the DMLs.

enable-batch-dml = false

影响范围

另外修改了大事务对CDC的方案会有很大的影响，需要进行考量和方案的商榷，大内存的事务方案会影响CDC接收和处理，基本上没办法处理，可以参考官网的描述：

​​​https://docs.pingcap.com/zh/tidb/stable/troubleshoot-ticdc/#ticdc-支持同步大事务吗有什么风险吗​​

其他参考

​​tidb开发规范​​ 运维实战

tidb开发规范 如果有不对的地方求留言指正 一 减少大事务 3.0的版本 1.1 每个事务内的 SQL 数量不超过 5000 条。 1.2 每个键值对不超过 6MB。 1.3 键值对的总大小不超过 100MB 1.4 键值对的总数不超过 300,000(总的行数*(1 + 索引个数) < 30万) 4.0版本 对大事务支持进一步优化 1.5 单个事务最大支持10GB 1.6 …

\

​​[FAQ] tidb 导入大量数据提示 8004 - Transaction is too large, size: xxx​​ TiDB 常见 FAQ

[问题澄清] tidb 导入大量数据提示 8004 - Transaction is too large, size: xxx [原因分析] 由于分布式事务要做两阶段提交，并且底层还需要做 Raft 复制，如果一个事务非常大，会使得提交过程非常慢，并且会卡住下面的 Raft 复制流程。为了避免系统出现被卡住的情况，我们对事务的大小做了限制： 单个事务包含的 SQL 语句不超过 5000 …

文章来源：