MySQL 8.0.22+ 已彻底移除 innodb_thread_concurrency，配置无效；真正影响并发性能的是 max_connections、innodb_read_io_threads、innodb_write_io_threads、innodb_purge_threads 等参数，需结合硬件与负载特征合理设置。
MySQL 8.0.22+ 已彻底移除 innodb_thread_concurrency，配了也无效，别再调它。
为什么 innodb_thread_concurrency 不该再碰
这个参数在 MySQL 5.6.27 被标记为 deprecated，8.0.22 正式删除。你在配置文件里写 innodb_thread_concurrency = 16，MySQL 启动时会打 Warning 日志，且完全不生效——InnoDB 改用自适应线程调度，不再靠硬限流控制并发。
继续纠结它，等于对着空气调参。真正影响多核利用率的是下面这几个参数：
-
max_connections：客户端连接总数上限，超了直接报Too many connections -
innodb_read_io_threads和innodb_write_io_threads：后台读/写 IO 线程数，默认各 4 -
innodb_purge_threads：清理线程数，默认 4，写密集场景可提到 6 -
innodb_parallel_read_threads（8.0.14+）：并行扫描时单个查询可用的读线程上限，默认 4
多核 CPU 下该调哪些线程参数
核心原则：不是“越多越好”，而是匹配硬件能力与负载特征。例如：
- SSD/NVMe 存储：可将
innodb_read_io_threads设为 8～12，innodb_write_io_threads设为 4～8；HDD 则保持默认 4 即可，调高反而引发寻道竞争 - 8 核服务器做 OLTP：推荐起点是
innodb_read_io_threads = 8、innodb_write_io_threads = 4、innodb_purge_threads = 4 - 写密集型（如日志表高频写入）：把
innodb_purge_threads提到 6，并关掉innodb_adaptive_hash_index避免 CPU 争用 - 超过
innodb_read_io_threads + innodb_write_io_threads > 24时，内核线程调度开销会上升，尤其低负载下响应反而变慢
调完怎么验证有没有效果
别只看 CPU 使用率。重点查这些指标：
- 执行
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests'和Innodb_buffer_pool_reads，比值应 > 20，否则说明 buffer pool 命中率低，IO 线程再高也没用 - 运行
iostat -x 1，观察%util是否持续 > 80%、await是否稳定；若Innodb_data_reads每秒极低，说明读请求早被 buffer pool 拦截，IO 线程压根没跑起来 - 查锁等待：
SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED LIMIT 5，看有没有长事务卡着；再结合performance_schema.data_locks定位具体锁哪一行 - 如果
Threads_created每秒增长 > 1，说明连接反复创建销毁，此时该调大应用端连接池idle timeout和 MySQL 的wait_timeout，而不是加线程
最容易被忽略的一点：所有线程参数都依赖底层资源支撑。比如开了 12 个 innodb_read_io_threads，但系统 I/O 调度器还是 mq-deadline，或者 MySQL 进程跨 NUMA 节点访问内存，性能照样上不去。
