MySQL 8.0 默认不自动利用多核CPU，需协同调优innodb_read_io_threads、innodb_buffer_pool_instances、innodb_thread_concurrency等参数；并行查询适用场景极窄且需严格配置，盲目开启反降性能。
MySQL 8.0 默认不会自动利用多核 CPU 加速查询，必须手动配置关键参数才能释放多核潜力；盲目开启并行查询反而可能降低性能。
哪些参数真正影响多核利用率
MySQL 多核能力不是靠“开个开关”就能用起来的，核心在三类参数协同：
-
innodb_read_io_threads和innodb_write_io_threads：控制 InnoDB 后台 I/O 线程数，直接影响磁盘并发读写能力。SSD 场景建议设为4～8（不是 CPU 核数，过高会引发线程调度争抢） -
innodb_buffer_pool_instances：缓冲池分片数。若设得太小（如默认 1），所有线程竞争同一把锁；32 核服务器建议设为16（≤64，且 ≥ CPU 核数 / 2） -
innodb_thread_concurrency：InnoDB 内部线程并发上限。设为0表示由 MySQL 自动管理更稳妥；若手动设，推荐64（32 核 × 2），但超过后线程排队反而拖慢响应
parallel_query 不是“多核加速万能钥匙”
MySQL 8.0.30+ 的并行查询是实验性功能，默认关闭，且适用场景极窄：
- 只对单表全表扫描或范围扫描生效；带
JOIN、GROUP BY、ORDER BY、子查询的语句完全不触发 - 必须同时设置三个变量才可能启用：
parallel_query = ON、parallel_threads_limit = 3（建议 2～4）、innodb_parallel_read_threads = 2（必须 ≥ 前者 − 1） -
EXPLAIN不显示并行信息，只能通过SHOW PROCESSLIST观察是否有parallel read thread状态线程，或查performance_schema.events_statements_history_long的SOURCE字段 - 它只缓解 CPU-bound 扫描瓶颈，对 I/O-bound 或内存不足场景几乎无效，甚至因额外线程开销拉低性能
容易被忽略的 CPU 资源浪费点
很多团队调了 innodb_read_io_threads 就以为完事了，却漏掉这些实际卡脖子环节：
- 连接数
max_connections设太高（比如 5000），每个连接都带独立sort_buffer_size和join_buffer_size，内存吃紧后触发 swap，CPU 反而大量耗在等待 I/O 上 -
thread_cache_size过小（如默认 0 或 8），高并发下频繁创建/销毁线程，内核调度压力陡增，SHOW STATUS LIKE 'Threads_created'持续上升就是信号 - 未关闭查询缓存（
query_cache_type = 0），MySQL 8.0 已移除该功能，但旧配置残留会导致启动失败或静默降级 - 日志刷盘策略
innodb_flush_log_at_trx_commit = 1虽安全，但在高并发 insert/update 场景下，会强制串行化 fsync，成为 CPU 和磁盘 I/O 的双重瓶颈；业务可接受秒级丢失时，改用2更平衡
多核优化不是堆参数，而是找瓶颈——先确认是 CPU bound 还是 I/O bound 或锁争用；perf top、pt-pmp 和 sys.schema_table_statistics_with_buffer 比盲目调 parallel_threads_limit 有用得多。
