MySQL 5.7 支持多核但需调优关键参数：innodb_read_io_threads 和 innodb_write_io_threads 应设为8–16（匹配物理核数），innodb_buffer_pool_instances 需按缓冲池大小合理设置（≥8G建议设16），并确保 open_files_limit、vm.swappiness 等系统级参数协同优化，否则多核无法真正并行。
MySQL 5.7 能用多核，但默认配置下多数线程会卡在锁竞争或单点瓶颈上，不是“不支持多核”，而是关键参数没调对、系统层没配合、并发模型有硬限制。重点不在堆核数，而在让读/写/I/O/刷盘等任务真正并行起来。
innodb_read_io_threads 和 innodb_write_io_threads 必须按核数设高
MySQL 5.7 废弃了旧的 innodb_file_io_threads，改用两个独立参数控制后台 I/O 线程数，默认都是 4——哪怕你有 24 核 CPU，I/O 仍被压在 4 个线程里排队。
- 真实场景中，SSD 或 NVMe 的随机 IOPS 很高，
innodb_read_io_threads和innodb_write_io_threads建议各设为8～16（不超过物理核数的 1.5 倍） - 必须同时开启
innodb_use_native_aio = ON（Linux 下默认已开，但要确认）；否则即使设了 16，实际仍走模拟 AIO，性能无提升 - 验证是否生效：
SHOW VARIABLES LIKE '%io_threads%';，再查SHOW ENGINE INNODB STATUS\G中的 “I/O thread” 段，看活跃线程数是否接近配置值
innodb_buffer_pool_instances 要匹配缓冲池大小和核数
缓冲池（innodb_buffer_pool_size）越大，越需要拆分成多个实例，否则所有线程争抢同一把 mutex，CPU cache line bouncing 严重，多核反而变慢。
- 规则：当
innodb_buffer_pool_size >= 1G时，innodb_buffer_pool_instances至少设为8；若缓冲池 ≥ 8G，建议设为16 - 不能盲目设高：实例数超过 CPU 物理核数（非超线程数），会导致上下文切换开销反超收益
- 检查方式：
SHOW VARIABLES LIKE 'innodb_buffer_pool_instances';，再结合SHOW STATUS LIKE 'Innodb_buffer_pool_wait_free';—— 若该值持续增长，说明实例数不足或 buffer pool 过小
系统级限制常被忽略：open_files_limit 和 vm.swappiness
MySQL 5.7 多核高并发下，连接数、表打开数、文件句柄消耗暴增，OS 层一卡，所有线程都在等文件操作，CPU 使用率虚高但吞吐不涨。
-
open_files_limit必须 ≥max_connections * 2（每个连接至少打开 1–2 张表），且需同步调 Linux 的nofile限制（/etc/security/limits.conf+systemctl daemon-reload） -
vm.swappiness = 1（不是 0）更稳妥：完全禁用 swap 在内存压力突增时可能触发 OOM killer 杀 MySQL；设为 1 可保底线又几乎不换出 -
innodb_thread_concurrency建议设为0（默认自动控制）或略高于物理核数（如 24 核设28），设成固定小值（如16）反而人为限速
真正卡住 MySQL 5.7 多核扩展性的，往往不是参数本身，而是 innodb_buffer_pool_instances 没拆、open_files_limit 被 OS 截断、或 innodb_read_io_threads 仍蹲在默认 4。调完别只看 CPU 利用率——要看 Threads_running 是否稳定、Innodb_data_reads 是否随核数线性上升、以及 SHOW PROCESSLIST 里有没有大量 Waiting for table flush 或 Waiting on mutex。
