设为2是最常用且有效的折中方案，可将tps提升3~10倍，但mysql崩溃或断电可能丢失最多1秒事务，需配合innodb_log_file_size等参数协同优化。
关闭 innodb_flush_log_at_trx_commit 降低日志刷盘频率
默认值 innodb_flush_log_at_trx_commit=1 表示每次事务提交都强制刷盘 redo log，对大批量插入是严重瓶颈。临时设为 2（每秒刷一次）或 0（仅写入 log buffer），可显著减少磁盘 I/O。
注意：0 和 2 会牺牲部分持久性（崩溃可能丢失最多 1 秒数据），仅限导入期间启用，导入完成务必恢复为 1。
- 推荐导入时设为
2：平衡速度与安全性 - 配合
autocommit=0手动控制事务，避免频繁 commit 触发刷盘 - 不要在生产环境长期使用
0或2
增大 innodb_buffer_pool_size 避免频繁页换入换出
innodb_buffer_pool_size 是 InnoDB 缓存数据和索引的核心内存区域。若小于待插入数据总量，会导致大量磁盘读写，拖慢插入速度。
MySQL 5.7 默认值通常为 128MB，对百万级以上插入远远不够。建议设为物理内存的 50%–75%，但需预留至少 2GB 给系统和其他进程。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 例如：16GB 内存机器，可设为
innodb_buffer_pool_size = 10G - 修改后必须重启 MySQL 生效
- 过大会导致 OS 内存不足，触发 OOM Killer，反而卡死
调大 innodb_log_file_size 提升大事务吞吐能力
InnoDB 的 redo log 文件太小（默认 48MB）会导致频繁 checkpoint，尤其在大批量插入时，log 文件很快写满并强制 flush 脏页，造成性能抖动。
将 innodb_log_file_size 提高到 512MB 或 1GB（单个文件），能大幅延长 log 循环周期，减少 checkpoint 频率。
- 修改前必须先停库、删除旧 log 文件（
ib_logfile0,ib_logfile1），再启动 - 总日志空间 =
innodb_log_file_size × innodb_log_files_in_group（默认为 2） - 不建议超过 2GB，否则 crash recovery 时间会显著变长
放宽 max_allowed_packet 和 net_buffer_length 防止批量语句被截断
拼接的多值 INSERT 语句一旦超过 max_allowed_packet（默认 4MB），MySQL 直接报错 Packets larger than max_allowed_packet are not allowed，整个批次失败。
同时，net_buffer_length 控制初始网络缓冲区大小，若太小，MySQL 可能反复 realloc，影响解析效率。
- 导入前设为
max_allowed_packet = 512M（需同步调整客户端连接参数） -
net_buffer_length = 1M即可，无需过大 - 这两个参数可在运行时动态修改（
SET GLOBAL），但建议写入my.cnf并重启以确保稳定
innodb_flush_log_at_trx_commit 和 max_allowed_packet 就可能提速 3–5 倍；但若跳过 buffer pool 和 log file 调整，后续插入仍可能因缓存争用或 checkpoint 拖慢——这些参数不是孤立生效的，漏掉任意一项都可能让优化打折扣。
