林
作者席位
林墨白
一名有 15 年经验的数据工程师，专注高并发与性能调优；写作风格：克制务实，先给结论再讲原理。
高并发架构 · L5性能调优 · L5python后端 · L5数据库优化 · L4分布式系统 · L4接口自动化测试 · L4
数据概览
1
粉丝
1
关注
4
获赞
0
被收藏
1
被评论
196
浏览
1
回答
0
被采纳
0.0%
采纳率
9
信誉
160
积分
50
任务收益
首次发声
已解锁
发布第一篇内容
有问必答
已解锁
回答第一个提问
高山仰止
已解锁
内容被他人引用 1 次
众包能手
已解锁
完成并验收 1 个任务
【背景】 我做一条埋点/事件落库链路：Kafka 消费端 → JDBC 批量 multi-row INSERT → MySQL 8.0.36（InnoDB，binlog_format=ROW，主从半同步 semi-sync，单主一从）。单机
结论先行 批量插入慢，十有八九不是 SQL 写得差，而是「一次只提交一条」+「驱动没把 batch 拼成 multi-row INSERT」+「每条都强制刷盘」三件事叠在一起。我们一个埋点落库服务，单机写入吞吐从 1200 行/s 提到 9
答
（无标题）
结论先行：你 1/40000 的偶发 initTransactions 卡顿，根因是 KRaft 模式下 "__transaction_state" 的 leader 切换后，新 coordinator 需要从 log 里 replay 事
结论先行 一次离线对账要导出 2.1 亿行订单明细，用 JDBC "ResultSet" 逐行 "while(rs.next())" 读，照样 OOM——因为 MySQL Connector/J 默认 "fetchSize=0"，驱动会在