MySQL 9.7 的 innodb_log_writer_threads 默认值：log_bin、核数与 cpuset 一起决定
MySQL 9.7 是 LTS 系列（GA 2026-04-21），这一版改动了 innodb_log_writer_threads 的默认值判定逻辑：不再只看逻辑 CPU 数量，还要看 log_bin 是否开启。与此同时，9.7 开始按 cpuset cgroup 计算可用逻辑 CPU（WL #16851），容器里限制 CPU 集合会改变参与判定的“核数”，从而可能让这个默认值发生翻转。
参考文档：
新规则：先分 log_bin，再看核数
if (log_bin = OFF) {
if (logical_cpus 4 | ON |
| ON | < 32 | OFF |
| ON | ≥ 32 | ON |
有两点需要注意。
第一，`log_bin=ON` 这条分支完全沿用旧规则，阈值仍是 32，没有变化。真正被改动的是 `log_bin=OFF` 的情况：阈值从 32 降到 4，小机器上更容易保持 OFF，4 核以上的实例则更早切到 ON。
第二，这条规则只影响**默认值**。如果配置里已经显式写了 `innodb_log_writer_threads=ON` 或 `OFF`，无论是在 my.cnf、命令行还是 SET GLOBAL，都不受这次变化影响；升级后不会有人悄悄改掉你手写的值。
## 9.7 起可用逻辑 CPU 按 cpuset 计算
9.7.0 的 InnoDB 变更项里有一条：服务器现在支持处理 cpuset cgroup 设置的资源限制，遵循 `cpuset-cpus` 控制器的约束，从而准确计算 MySQL Server 可用的逻辑 CPU 数量（WL #16851）。
这意味着在容器或 `systemd` 里用 `--cpuset-cpus`、`AllowedCPUs=` 绑核之后，参与上面判定的不再是宿主机的物理核数，而是这个 cpuset 里实际可用的核数。一个 64 核宿主机上 `--cpuset-cpus=0-3` 的容器，在 `log_bin=OFF` 时会被算成 4 个逻辑 CPU，正好落在 `<= 4` 的边界上，默认值保持 OFF；绑到 `0-4` 就变成 5 个，默认值翻到 ON。核数没变，容器规格没变，只是 cpuset 从 4 个核变成 5 个核，redo 写入线程的默认形态就变了。
这也是升级前值得复核的地方：同一份 my.cnf 跑在旧版本和 9.7 上，实际生效的 `innodb_log_writer_threads` 可能不同。
## 核查方法
先看当前生效值和 `log_bin`：
```sql
SHOW VARIABLES LIKE 'innodb_log_writer_threads';
SHOW VARIABLES LIKE 'log_bin';
再确认服务器实际认定的可用 CPU 集合：
cat /sys/fs/cgroup/cpuset.cpus.effective
nproc
cpuset.cpus.effective 是 cgroup 视角下最终生效的集合，nproc 是进程视角的可用 CPU 数，两者对照基本能判断 9.7 会拿到哪个数字。宿主机上直接部署、没有 cpuset 限制时，它约等于 grep -c processor /proc/cpuinfo 的结果。
取舍：什么时候留 OFF，什么时候开线程
innodb_log_writer_threads=OFF 时，redo 写入由用户线程自己做；ON 时交给专用的 log writer / log write notifier 线程。前者在低并发下少一层线程唤醒和交接，后者把写 redo 的工作从提交路径上剥离出去，让前台事务少等。
- 事务并发低、提交稀疏，比如单机小库、开发测试实例、串行批处理：保持 OFF 更省事，专用线程大多时间空转。
- 高并发短事务、提交密集，redo 写入成为提交路径上的等待点：开线程通常有收益，尤其是
log_bin=ON时 binlog 组提交与 redo flush 交织，独立写线程能减少彼此阻塞。 - 存储本身写带宽吃紧时，换成专用线程并不会让磁盘变快，只是改变了等待发生的位置，这种情况先看磁盘，不要指望改这个参数。
至于到底该不该开，不要对着默认值猜。先量 redo 写压力：用 SHOW GLOBAL STATUS 观察 Innodb_os_log_written 的增长速率和 Innodb_log_write_requests、Innodb_log_waits，再结合提交速率判断写入是不是瓶颈。有条件就在同规格实例上把两种取值各跑一遍，对比自己的业务指标，而不是套用别人的结论。