调高写入速度最直接有效的手段是调整innodb_flush_log_at_trx_commit，但需权衡数据丢失风险：设为0时每秒刷盘、MySQL崩溃最多丢1秒数据；设为2时提交写入OS缓存、仅断电或OS崩溃可能丢1秒数据；适用于批量导入、测试库重建等可接受丢失的场景，生产OLTP严禁设0，设2也需评估RPO；需动态修改后验证全局与会话值，并同步调整sync_binlog以避免瓶颈。
调高写入速度最直接有效的手段，就是改 innodb_flush_log_at_trx_commit，但必须清楚它丢数据的风险边界。
为什么改这个参数能明显提速
默认值 innodb_flush_log_at_trx_commit = 1 要求每次事务提交都触发一次磁盘 fsync()，而机械盘或普通 SSD 的 fsync() 延迟常在毫秒级。批量插入时，成千上万次小事务会把 I/O 卡死。
改成 0 或 2 后，日志刷盘从“每事务一次”变成“每秒一次”，I/O 次数骤降 90% 以上，实测插入吞吐可从几百行/秒跳到上万行/秒。
-
0：log buffer 每秒刷一次到磁盘，MySQL 进程崩溃会丢最多 1 秒数据 -
2：log buffer 每次提交写入 OS page cache，OS 每秒刷盘一次；MySQL 崩溃不丢数据，仅主机断电/OS 崩溃才可能丢 1 秒
哪些场景适合临时设为 0 或 2
不是所有写入都值得牺牲持久性。只在明确接受数据丢失风险的批量操作中启用：
- 导入历史数据、重建测试库、ETL 中间表填充
- 从库初始化（尤其配合
SET sql_log_bin = 0） - 离线分析库、日志归档表等对实时一致性无要求的场景
- 压测或性能验证阶段
生产环境 OLTP 业务、支付类事务、用户核心状态变更，严禁设为 0；设为 2 也需评估 RPO（恢复点目标）是否允许秒级丢失。
线上修改和回滚要小心这些细节
该参数支持在线动态修改，但要注意作用范围和副作用：
- 执行
SET GLOBAL innodb_flush_log_at_trx_commit = 2;立即生效，但新连接才继承该值；已有连接仍用旧值 - 若使用连接池（如 PHP-FPM、Java Druid），需重启应用或等待连接重建，否则无效
- 修改后务必确认：运行
SELECT @@innodb_flush_log_at_trx_commit;查当前会话值，再查SELECT @@GLOBAL.innodb_flush_log_at_trx_commit;确认全局值 - 导入完成后，必须立刻改回
1，否则后续所有事务都处于弱持久状态
别依赖配置文件重启生效——批量导入往往等不及重启，且重启本身有服务中断成本。
别只盯这一个参数，sync_binlog 得同步调
单独改 innodb_flush_log_at_trx_commit 效果会被 sync_binlog 卡住。例如 sync_binlog = 1 时，即使 redo log 每秒刷，binlog 仍每事务强制刷盘，瓶颈还在。
建议组合策略：
- 追求极致速度且可丢 binlog：设
sync_binlog = 0（依赖 OS 刷盘） - 平衡安全与速度：设
sync_binlog = 1000，配合innodb_flush_log_at_trx_commit = 2 - 绝对不允许 binlog 丢失（如主从复制）：至少保持
sync_binlog = 1，此时innodb_flush_log_at_trx_commit改成2仍有提升，但不如配0明显
双 1（innodb_flush_log_at_trx_commit = 1 + sync_binlog = 1）是唯一强一致方案，但也是性能天花板最低的组合——别指望它扛高并发写入。
