innodb_flush_log_at_trx_commit=2是写密集场景最常用折中值：每次事务提交写入os缓存，内核每秒fsync刷盘，崩溃最多丢失1秒数据，qps可提升3–5倍，兼顾安全性与性能。
innodb_flush_log_at_trx_commit 怎么设才不丢数据又不太慢
这是写性能最敏感的开关，直接决定事务日志何时落盘：
-
innodb_flush_log_at_trx_commit = 1：每次COMMIT都强制刷盘到磁盘。强一致性保障，但 SSD 也扛不住高并发小事务（如每秒数千次INSERT） -
innodb_flush_log_at_trx_commit = 2：每次COMMIT写入 OS 缓存，由内核每秒fsync()刷一次。崩溃最多丢失 1 秒数据，实测 QPS 可提升 3–5 倍，是写密集型生产环境最常用折中值 -
innodb_flush_log_at_trx_commit = 0：仅每秒刷一次日志，性能最好，但机器断电或内核 panic 可能丢失最多 1 秒事务——金融、支付类业务禁用
注意：sync_binlog 必须同步调整。若开启 binlog（如主从复制），建议设为 sync_binlog = 1 或 sync_binlog = 2，避免主从数据不一致。
如何用 Resource Group 绑定写线程到特定 CPU 核心
MySQL 8.0 的 CREATE RESOURCE GROUP 不调度事务，而是调度执行线程。对写密集型负载，可把批量导入、ETL 或高优先级写会话绑定到专用 CPU，避免被报表查询抢占：
- 先确认 CPU topology：
cat /proc/cpuinfo | grep "processor\|physical id\|core id" - 创建写专用组（假设物理 CPU 0–1 专供写）：
CREATE RESOURCE GROUP write_high_priority TYPE = USER VCPU = 0-1 THREAD_PRIORITY = -10;
- 给用户分配组：
ALTER USER 'etl_user'@'%' RESOURCE GROUP write_high_priority;
- 或运行时绑定当前会话：
SET RESOURCE GROUP write_high_priority;
⚠️ 注意：资源组只对 TYPE = USER 线程生效；后台线程（如 innodb_io、binlog_dump）不受控。且 THREAD_PRIORITY 在 Linux 上依赖 pthread_setschedparam()，需 MySQL 进程有 CAP_SYS_NICE 权限（systemd service 中加 CapabilityBoundingSet=CAP_SYS_NICE）。
写密集场景下哪些并发参数必须调
默认配置在大批量 INSERT 或 UPDATE 时容易卡住，关键不是“开更多线程”，而是让线程更高效协作：
-
innodb_thread_concurrency = 0：推荐设为 0，让 InnoDB 自动根据 CPU 核心数调节，避免人为限制反成瓶颈 -
innodb_write_io_threads = 8（SSD）或4（HDD）：写 IO 线程数，别超过物理核心数 × 2 -
thread_cache_size = 16：避免频繁创建/销毁连接线程。可通过Threads_created状态变量监控是否偏高（持续增长说明不够） -
innodb_log_file_size = 2G：日志文件越大，越少 checkpoint，写吞吐越高；但重启恢复时间变长。建议单个文件 ≥ 1G，总大小（innodb_log_files_in_group × innodb_log_file_size）不低于 4G
别碰 innodb_lock_wait_timeout 来“加速写”——它只影响锁等待超时时间，不能减少锁争用本身；真有锁冲突，得靠索引优化或拆分事务粒度。
为什么批量写入还要关 autocommit + 手动 commit
即使 innodb_flush_log_at_trx_commit = 2，每条语句自动提交仍带来巨大日志开销。真实写密集场景必须显式控制事务边界：
- 错：
INSERT INTO t VALUES (1); INSERT INTO t VALUES (2); ...
（每行一个事务） - 对：
SET autocommit = 0; INSERT INTO t VALUES (1),(2),(3),...,(1000); COMMIT;
（每千行一事务）
同时注意：max_allowed_packet 要足够大（如 64M），否则大批次 INSERT 会被截断；innodb_buffer_pool_size 必须充足，否则大量脏页刷盘反而拖慢整体写入。
