大事务提交为什么总是慢半拍用过 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