重点调 innodb_flush_log_at_trx_commit 和 sync_binlog 两个参数：前者设为 2（日志写入 os 缓存），后者设为 0 或 1000（关闭或批量同步 binlog），必须协同配置才能显著提升 tps 并控制数据丢失风险。
Java 应用连接 MySQL 处理高并发写入时，刷盘策略的核心不在 Java 层，而在于 MySQL 服务端的两个关键参数协同配置：innodb_flush_log_at_trx_commit 和 sync_binlog。Java 侧只需确保事务控制得当、批量语句构造正确，就能让这些策略真正生效。
重点调哪两个参数？必须一起改
这两个参数决定 redo log 和 binlog 的落盘时机，直接影响每秒写入能力（TPS）和崩溃后数据丢失风险：
- innodb_flush_log_at_trx_commit = 2：事务提交时只把日志写入操作系统缓存（OS buffer），不立即刷盘；MySQL 崩溃不丢数据，但若整个服务器断电或内核崩溃，最多丢失最近 1 秒内的事务。实测吞吐常提升 2–3 倍。
- sync_binlog = 0 或 1000：设为 0 表示完全依赖 OS 刷盘，风险高；设为 1000 表示每累计写入 1000 次 binlog 才触发一次 fsync，大幅减少磁盘同步次数。主从延迟会略增，但对多数非金融类业务可接受。
单独改其中一个效果有限。例如只设 innodb_flush_log_at_trx_commit=2 但 sync_binlog=1，binlog 仍每笔都刷盘，瓶颈还在。推荐组合是 2 + 1000，兼顾性能与主从一致性底线。
Java 代码怎么配合？别让批量失效
即使 MySQL 参数调优了，Java 端若还用单条 INSERT 循环，照样卡在协议解析、网络往返和事务开销上：
- 禁用 autocommit，显式用
connection.setAutoCommit(false)开启事务，最后统一commit()。 - 把 100–500 行数据拼成一条多值 INSERT：
INSERT INTO t (id, name) VALUES (?, ?), (?, ?), ... - 使用
PreparedStatement.addBatch()+executeBatch()，避免 SQL 解析重复消耗。 - 单批总大小控制在 1MB 内，别超 MySQL 的
max_allowed_packet（默认 64MB，但过大易触发 OOM 或锁等待）。
什么场景别用 ON DUPLICATE KEY UPDATE
Java 里常用它做“存在则更新、不存在则插入”，但在高并发下极易引发间隙锁争用：
- 唯一键冲突频繁时（如设备心跳上报、订单幂等写入），InnoDB 会升级为 next-key lock，导致大量线程卡在 Updating rows 状态。
- 更稳妥的做法是：应用层先查（SELECT … FOR UPDATE），再根据结果 INSERT 或 UPDATE，或直接用分布式锁+状态机保障幂等。
- 注意：ON DUPLICATE KEY UPDATE 即使没冲突，也会分配自增 ID，造成 ID 空洞，影响监控判断。
其他配套建议
光调刷盘还不够，需整体配合：
- 表结构用自增 BIGINT 主键，避免 UUID 引发页分裂；减少二级索引数量，每个索引都会在写入时额外更新一棵 B+ 树。
- 日志类、埋点类数据可进一步异步化：Java 发送到 Kafka/RabbitMQ，由消费者线程批量落库，彻底解耦写压力。
- 确认文件系统支持
innodb_flush_method=O_DIRECT（绕过 OS 缓存），尤其在 SSD 环境下能稳定发挥 I/O 性能，且与 doublewrite 机制兼容。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
