MySQL 5.7 能用多核，但默认 innodb_read_io_threads 和 innodb_write_io_threads 均为4，严重限制I/O并行能力；需设为8～16（≤物理核数1.5倍），并确保 innodb_use_native_aio=ON、innodb_buffer_pool_instances 匹配核数与缓冲池大小、open_files_limit 与系统 nofile 同步调高，四者协同方可真正发挥多核效能。
innodb_read_io_threads 和 innodb_write_io_threads 必须调高，否则多核 CPU 大部分闲置
MySQL 5.7 能用多核，但默认值（各为 4）会让 I/O 成为瓶颈。哪怕你有 24 核 CPU，只要这两个参数没改，后台读写线程就卡死在 4 个，SSD 或 NVMe 的高 IOPS 完全发挥不出来。
-
innodb_read_io_threads和innodb_write_io_threads建议都设为 8～16，上限不超过物理核数的 1.5 倍 - 必须确认
innodb_use_native_aio = ON（Linux 下默认开启，但需查证；Windows 不支持 native AIO，设高也无效） - 验证是否生效：执行
SHOW VARIABLES LIKE '%io_threads%';，再运行SHOW ENGINE INNODB STATUS\G，在 “I/O thread” 段看活跃线程数是否接近配置值 - 错误现象：CPU 使用率 30%～50%，但 QPS 上不去、慢查询增多、
Innodb_buffer_pool_wait_free持续上涨
innodb_buffer_pool_instances 设错会导致多核争抢 mutex
缓冲池实例数不是越大越好。当 innodb_buffer_pool_size ≥ 8G 时，设为 16 是合理起点；但若物理核数只有 8，设成 32 就会引发频繁上下文切换，反而拖慢性能。
- 实例数应 ≤ 物理 CPU 核数（不是逻辑核/超线程数）
- 检查争抢：观察
SHOW STATUS LIKE 'Innodb_buffer_pool_wait_free';，非零且持续增长说明实例太少或 buffer pool 过小 - 常见误配：把
innodb_buffer_pool_instances和innodb_buffer_pool_size同步按比例放大（比如 buffer pool 从 4G 扩到 16G，就把 instances 从 4 改成 16），忽略了核数约束
系统级限制不调，MySQL 再怎么优化也卡在 OS 层
MySQL 5.7 高并发下文件句柄消耗极快，open_files_limit 和 Linux 的 nofile 限制必须同步调高，否则连接一多就报 Too many open files，所有线程阻塞在文件打开环节。
-
open_files_limit至少设为max_connections * 2（每个连接常打开 1～2 张表） - Linux 端需修改
/etc/security/limits.conf：mysql soft nofile 65535 mysql hard nofile 65535
并执行systemctl daemon-reload -
vm.swappiness = 1更稳妥：设为 0 可能在内存突增时触发 OOM killer 杀 MySQL；设为 1 几乎不换出，又保留底线
innodb_flush_log_at_trx_commit 和 sync_binlog 的取舍要匹配业务场景
这两个参数直接决定事务持久性与吞吐量的平衡点，不能盲目设 1。
- OLTP 场景（如订单写入）：可接受短暂丢失（秒级），建议
innodb_flush_log_at_trx_commit = 2+sync_binlog = 0，吞吐提升明显 - 金融/账务类场景：必须
innodb_flush_log_at_trx_commit = 1+sync_binlog = 1，但要确保磁盘是 SSD/NVMe，否则写入延迟飙升 - 错误搭配：
innodb_flush_log_at_trx_commit = 2却配sync_binlog = 1，会导致 binlog 和 redo log 不一致，主从复制断裂
真正卡住多核并行的，往往不是某一个参数，而是 I/O 线程、buffer pool 实例、文件句柄、内核参数这四者没对齐。调参时漏掉任意一环，CPU 使用率看着高，实际有效吞吐却上不去。
