innodb_flush_log_at_trx_commit和sync_binlog共同控制事务提交时redo log与binlog刷盘频率：设为0/2和0/n可将百万行导入的刷盘次数从100万次降至数百次，大幅提升写入性能，但会牺牲部分数据安全性，需配合禁用索引校验、外键检查及导入后重建索引才能实现8–15倍整体提速。
关闭 innodb_flush_log_at_trx_commit 和 sync_binlog 的真实作用
因为这两个参数共同决定了“每次事务提交是否强制刷盘”。默认值 innodb_flush_log_at_trx_commit=1 + sync_binlog=1（即“双一”）意味着：每条 INSERT 语句提交时，都要把 redo log 和 binlog 同时落盘。磁盘 I/O 成为绝对瓶颈，尤其在机械盘或高并发写入场景下，吞吐量被压到极低水平。
设你导入 100 万行数据，若每行一个事务（如单条 INSERT），就要触发 100 万次刷盘；而关掉双一后，redo log 可缓存在内存（=0 或 =2），binlog 可批量同步（sync_binlog=0 或较大值），实际刷盘次数可能降到几百次甚至一次。
不同取值对数据安全与性能的权衡
这不是“开或关”的二选一，而是按场景选值：
-
innodb_flush_log_at_trx_commit=0：log buffer 每秒刷一次，崩溃最多丢 1 秒数据；适合纯临时数据导入，不可用于生产环境有事务一致性要求的场景 -
=2：每次 commit 写入 OS cache，但不 fsync；崩溃不丢数据（OS 不崩），但断电可能丢 cache 中未刷盘日志；平衡性较好，推荐用于大批量导入 -
sync_binlog=0：binlog 完全由 OS 控制刷盘时机；=1000表示每 1000 次事务刷一次；值越大越快，但也越可能丢失最近若干事务的 binlog（影响主从同步和 PITR）
为什么只改这两个还不够？必须配套禁用索引和外键检查
即使双一关闭，如果表上有唯一索引或外键，MySQL 仍需为每一行做约束校验、B+树定位、间隙锁判断——这些操作本身不刷盘，但 CPU 和内存开销巨大，且无法批量优化。
实操中必须同步执行：
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
SET unique_checks=0;：跳过唯一索引插入前的查重逻辑（导入后再=1并ANALYZE TABLE） -
SET foreign_key_checks=0;：绕过外键依赖扫描和父表锁检查 - 导入完成再恢复：
SET unique_checks=1; SET foreign_key_checks=1;
漏掉任意一项，速度可能只提升 2–3 倍；四项全做（双一 + 索引 + 外键），常见提升 8–15 倍。
导入后务必重建索引，否则查询会变慢
禁用 unique_checks 不等于删除索引，而是跳过校验。索引结构仍在，但大量无序数据插入会导致页分裂严重、B+树深度异常、叶节点碎片率飙升——此时 SELECT 性能反而比导入前更差。
正确做法是：
- 导入完成后立即执行
ALTER TABLE t ENGINE=InnoDB;（快速重建聚簇索引） - 或使用
OPTIMIZE TABLE t;（MySQL 5.7+ 对 InnoDB 效果等价） - 避免在导入中途加索引，那会触发全表重建两次
这个步骤常被跳过，结果是“导入快了，查得更卡”，问题反而更隐蔽。
