批量提交与合理事务拆分是高并发写入的核心优化手段：批量INSERT降低日志刷盘开销，每批100–1000行；拆大事务为每1000–5000条一个小事务；调优innodb_flush_log_at_trx_commit或synchronous_commit以平衡吞吐与一致性；分散热点、减少索引、分表分区缓解争用。
高并发写入场景下，SQL性能瓶颈往往不在单条语句本身，而在事务开销、锁竞争和日志刷盘频率。批量提交与合理事务拆分是见效快、改动小的核心优化手段。
批量插入代替逐条插入
单条INSERT触发一次网络往返、一次日志写入、一次缓冲区刷新，吞吐量极低。改用批量INSERT可显著降低单位记录的开销：
- MySQL推荐每批100–1000行（具体视单行数据大小调整，避免超过
max_allowed_packet） - PostgreSQL可用
INSERT ... VALUES (...), (...), (...)语法，或配合COPY命令实现更高吞吐 - 避免在循环内拼接超长SQL字符串，建议用预编译+参数化批量绑定（如JDBC的
addBatch()+executeBatch()）
控制事务粒度：拆大事务为小事务
一个包含数万条INSERT的大事务会带来严重问题：锁持有时间长、undo日志膨胀、主从延迟加剧、失败后回滚代价高。应按业务语义或固定数量拆分：
- 每1000–5000条写入封装为一个独立事务（需结合表锁类型、索引更新成本实测调整）
- 避免跨事务破坏业务一致性——若必须原子性，考虑用应用层幂等+最终一致性替代强事务
- 注意自动提交模式：显式
BEGIN/COMMIT比依赖默认autocommit更可控
减少日志与刷盘压力
事务提交时的redo/ WAL刷盘是常见瓶颈。可在保障数据安全前提下适度调优：
- MySQL中设置
innodb_flush_log_at_trx_commit = 2（崩溃可能丢失1秒数据，但写入吞吐可提升数倍） - PostgreSQL中调整
synchronous_commit = off（异步提交），适用于允许短暂数据不一致的写密集场景 - 确保磁盘I/O能力匹配——批量写入放大了IO压力，SSD和合理RAID配置不可省略
避开热点行与索引争用
即使批量+小事务，若所有写入集中到同一张表的自增主键尾部或某个分区，仍会引发页级锁或缓冲池争用：
- 写入前对主键或分片键做随机化扰动（如UUID前缀+时间戳），分散物理位置
- 高频写入表避免过多二级索引，写入后批量构建索引比实时维护更高效
- 考虑分表或逻辑分区（如按天/按用户哈希），把并发压力分散到多个物理对象
不复杂但容易忽略：批量提交和事务拆分不是“越大越好”或“越小越好”，关键是在吞吐、延迟、一致性、恢复能力之间找平衡点。上线前务必用真实数据压测验证。
