改innodb_flush_log_at_trx_commit能提速，因其默认值1要求每次事务提交都fsync写盘，i/o开销大；设为2或0可跳过同步刷盘，tps提升30%–50%，但需权衡数据安全并配合sync_binlog等参数。
直接改 innodb_flush_log_at_trx_commit 能显著提速，但不是“设成 0 就完事”——它和你的数据安全边界、硬件环境、是否配合其他参数，强相关。
为什么改这个参数能提速
默认值 1 要求每次事务提交都把 redo log 写入磁盘并 fsync，这是 ACID 中持久性的保障，但也是 I/O 瓶颈所在。大批量导入本质是高频小事务（尤其用 INSERT），每行都刷盘，磁盘扛不住。
改成 2 后，log 只写进操作系统缓存，由 OS 异步刷盘；改成 0 则完全交给后台线程每秒统一刷一次。两者都跳过了同步磁盘 I/O，实测 TPS 可提升 30%–50%。
注意：innodb_flush_log_at_trx_commit 和 sync_binlog 是联动的。单独调一个效果有限，建议一起看。
不同取值的风险与适用场景
innodb_flush_log_at_trx_commit = 0：性能最高，但 MySQL 进程崩溃时，最多丢失最近 1 秒所有事务。只适合日志表、临时分析表等可丢数据的场景。
innodb_flush_log_at_trx_commit = 2：折中选择。只要操作系统不崩、不断电，事务不会丢。MySQL 崩溃不影响恢复，因为 redo log 已在 OS 缓存里，重启后仍可重放。电商订单导入、从库初始化常用这个值。
innodb_flush_log_at_trx_commit = 1：金融类系统必须用，但导入前如果已确认这批数据不参与实时交易（比如历史归档），就别硬扛着用它。
- 不要在线设为
0后又长期开着——导入完务必切回1或2 - SSD 环境下，
2和1的性能差距比 HDD 小；有电池缓存的 RAID 卡时，2更可靠 - 若同时启用了 binlog，记得配好
sync_binlog（比如设为1000），否则主从一致性可能出问题
怎么安全地临时修改
优先用会话级动态设置，避免影响其他连接：
SET SESSION innodb_flush_log_at_trx_commit = 2;
如果你确定整个导入过程都走同一个连接（比如用 mysql 客户端执行 SQL 文件），这就够了。不需要改全局或重启。
如果用的是脚本批量连接（如 Python + PyMySQL），就得在每个连接建立后立刻执行该 SET 语句。
常见错误：
- 误用
SET GLOBAL：会影响所有新连接，线上业务可能意外降级持久性 - 忘记关 autocommit：即使
innodb_flush_log_at_trx_commit = 2，每条 INSERT 仍是独立事务，没合并就白调了 - 导入中途断开连接：会话级设置失效，后续连接恢复默认值，容易漏切
必须配套做的几件事
单靠改 innodb_flush_log_at_trx_commit 效果有限，这几个动作几乎必做：
- 导入前执行
SET unique_checks = 0和SET foreign_key_checks = 0，避免逐行校验唯一索引和外键 - 用
LOAD DATA INFILE替代 INSERT —— 它不走 SQL 解析层，快 5–20 倍；文件必须放在 MySQL 服务端，路径得符合secure_file_priv - 导入 SQL 文件时，开头加
SET autocommit = 0;，结尾加COMMIT;，把万级数据包进一个事务 - 导入后立即恢复检查：
SET unique_checks = 1;、SET foreign_key_checks = 1;，否则后续 DML 可能静默失败
最容易被忽略的是：改完参数后没验证是否生效。执行 SELECT @@innodb_flush_log_at_trx_commit; 确认当前会话值，别凭记忆操作。
