如何在my.cnf中配置MySQL 8.0以支持大规模并发插入？

innodb_flush_log_at_trx_commit=2是高并发写入的关键优化项，设为2时事务仅写入OS缓存、每秒fsync一次，吞吐提升3–5倍，但主机断电可能丢失最多1秒数据。

innodb_flush_log_at_trx_commit=2 是并发插入提速的关键开关

MySQL 8.0 默认值 innodb_flush_log_at_trx_commit = 1 每次事务都强制刷盘，安全但严重拖慢写入吞吐。对非金融类业务，设为 2 可让日志先写入 OS 缓存，性能提升常达 3–5 倍。

必须注意：2 意味着主机断电或内核崩溃时，最多丢失 1 秒事务；0 虽更快但风险更高，不建议生产环境使用。

1. 确认当前值：mysql -e "SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';"
2. 修改位置：仅在 [mysqld] 段生效，写错段（如 [client]）完全无效
3. 搭配 sync_binlog = 2000 可进一步降低 binlog 刷盘频率，但需确保业务能容忍主从延迟增大

thread_cache_size 必须按 Threads_created 实际增速来调

高并发插入会频繁建立新连接，若 thread_cache_size 过小，线程反复创建销毁会吃光 CPU。这不是“设个固定值就行”的参数，得看实时指标。

典型错误是直接套用公式或盲目设成 256——内存涨了，Threads_cached 却长期卡在 10 以下，说明根本没被复用。

1. 查速率：SHOW GLOBAL STATUS LIKE 'Threads_created';，间隔 60 秒再查一次，差值 ÷ 60 得每秒新建线程数
2. 每秒新建 > 10 → 起始设 thread_cache_size = 32；> 20 → 试 64 或 128
3. 观察 1 小时后 Threads_cached 是否稳定在设定值的 60%–90%，否则继续调

skip-log-bin 能省掉一半写入开销，但只适用于无主从/无备份场景

MySQL 8.0 默认开启 log-bin，所有写操作额外写一次 binlog。对纯写入密集型服务（如日志归集、埋点入库），这个开销不可忽视。

一旦启用 skip-log-bin，不仅减少磁盘 IO，还能绕过 binlog 与 redo log 的两阶段提交协调逻辑，实测插入延迟下降 40%+。

1. 仅限单机、无灾备需求的场景；只要用到主从复制、GTID、PXC 或任何基于 binlog 的工具（如 Canal、DMS），就不能关
2. 配置项必须写在 [mysqld] 下，且重启后才生效；动态执行 SET GLOBAL sql_log_bin = OFF 只对当前会话有效，不解决全局压力
3. 验证是否关闭：mysql -e "SHOW VARIABLES LIKE 'log_bin';" 返回 OFF 才算成功

innodb_buffer_pool_size 和 innodb_log_file_size 要同步调大

单纯调高 innodb_buffer_pool_size 不足以支撑大规模并发插入——如果重做日志太小，InnoDB 会频繁 checkpoint，反过来逼迫 buffer pool 刷脏页，形成恶性循环。

二者必须协同：buffer pool 大了，log file 也得跟上，否则写入吞吐卡在日志刷盘瓶颈上。

1. innodb_buffer_pool_size：16GB 内存服务器建议设 10G，留足 4–5GB 给 OS 和连接线程
2. innodb_log_file_size：对应设 1G～2G（不是总和，是单个文件大小），设完必须删除旧日志文件并重启，否则 MySQL 拒绝启动
3. 验证日志是否生效：ls -lh /var/lib/mysql/ib_logfile*，文件大小应与配置一致

实际压测中，这四点配齐后，5 字段单行插入从 80ms 降到 12ms 是常见结果。最易被忽略的是 innodb_log_file_size 修改后不删旧文件就重启——MySQL 报错退出，但错误日志里那句 InnoDB: Error: log file ./ib_logfile0 is of diffe... 很容易被扫一眼跳过。