大事务提交总是卡？GreatSQL 让 binlog "零拷贝"落盘，延迟直降七成 ...

大事务提交，为什么总是"慢半拍"？

用过 MySQL / GreatSQL 的 DBA 大概都遇到过这样的场景：一个大事务提交，整个库仿佛被按了暂停键——TPS 突然抖动，其他事务排队等待，I/O 打满。

根子出在传统 binlog 的提交流程上。大事务提交时，要把已经落在磁盘上的 binlog cache 重新读出来，再二次写入 binlog 文件。这套"缓存回读 + 二次写入"的动作，带来一连串代价：

• 高 I/O 消耗，同样的数据要写两遍（写放大）；
• 长时间持有 binlog 锁，阻塞其他事务提交；
• TPS 波动明显，高并发下尤为难受。

事务越大，这段路走得越痛。

GreatSQL 8.4.4-5 的解法：让 binlog cache 文件"直接变身"binlog 文件

GreatSQL 在 8.4.4-5 版本带来了「大事务 binlog 独立落盘」特性。核心思路一句话：

不再回读重写，而是把 binlog cache 文件直接"转正"成 binlog 文件。

传统路径是：binlog cache → 读取 → 写入 binlog 文件 → 提交（存在二次 I/O）。

优化后路径变成：binlog cache → 预构建 → rename → 提交（零二次写 I/O）。

提交链路直接缩短，I/O 延迟自然大幅下降。

背后的三项关键改造

• 可重构的 cache 文件结构：binlog cache 在写入时就预留好 File Header、Format Description Event、Previous GTID、GTID Event 以及对齐 padding 空间，让它天生具备"可直接当 binlog 文件用"的结构。
• 直接 rename 落盘机制：满足条件时，结束当前 binlog 文件、把 header events 写入 cache 预留空间，再把 cache 文件直接 rename 成正式 binlog 文件。
• checksum 状态继承：独立落盘期间关闭 binlog checksum，后续写入同一文件的事务继承该状态，rotate 时同步传播，保证文件一致性。

性能收益：延迟降 30%~70%，TPS 提升 10%~40%

在大事务场景下，这套优化带来的收益相当直接：

• 大事务提交延迟降低 30%~70%；
• 高并发场景 TPS 提升 10%~40%；
• binlog 写放大减少，I/O wait 明显下降，TPS 波动收敛。

怎么用？一个参数就够

优化由参数 binlog_large_commit_threshold 控制：

• 类型：ulonglong，默认值 128MB；
• 含义：触发大事务优化的阈值，事务大小达到该值即启用。

启用还需满足几个条件：binlog cache 已发生落盘（非纯内存）、未混用 stmt/trx cache、未开启 binlog 压缩或加密、end_log_pos 校验通过。

稳不稳？兼容和回退都考虑到了

• 完全兼容 MySQL binlog 协议与 GTID 体系，mysqlbinlog 正常解析，不影响主从复制逻辑，不改变事务语义；
• 遇到预留空间不足、end_log_pos 不一致、checksum 异常、文件系统失败等情况，会自动回退到传统写入模式，安全兜底；
• 开启 binlog 压缩 / 加密、cache 混用等场景不启用该优化，行为与原来一致。

一句话总结：GreatSQL 8.4.4-5 通过重构 binlog cache 文件模型，让大事务具备"零拷贝式落盘"能力，从根子上砍掉了 binlog 写入路径的 I/O 放大，是高负载场景下提升稳定性的一把利器。

特性详情见 GreatSQL 8.4.4-5 官方文档：https://greatsql.cn/docs/8.4.4-5/5-enhance/5-1-highperf-binlog-flush-opt-large-trx.html