mysql多核扩展性受限于锁竞争、上下文切换和内存一致性开销；innodb_thread_concurrency设为0会加剧全局锁争抢，建议设为cpu核心数×2，并关闭自适应哈希索引；io线程数需按核数调至8或12；thread_cache_size应设为max_connections×0.1；innodb_spin_wait_delay需结合压测调整。
MySQL 在多核 CPU 下的扩展性不是线性增长的，根本原因在于锁竞争、上下文切换和内存一致性开销，而不是“核心没跑满”这种表象问题。单纯加核或调高并发参数反而容易让性能下降。
innodb_thread_concurrency 设成 0 反而更慢？
这是最常踩的坑。innodb_thread_concurrency 控制的是 InnoDB 内部可同时执行的用户线程数，不是连接数，也不是操作系统线程数。设为 0 表示“不限制”，但在多核场景下，大量线程会争抢 kernel_mutex、dict_operation_lock 等全局锁，导致 CPU 空转和频繁上下文切换。
- 建议值 ≈ CPU 核心数 × 2（仅适用于高并发 OLTP 场景；低负载或 SSD 存储可保持 0）
- 必须配合
innodb_adaptive_hash_index = OFF（尤其 MySQL 5.7+），否则哈希索引自适应逻辑会在高并发下成为 CPU 热点 - 观察
Innodb_mutex_os_waits和Innodb_row_lock_waits，若数值持续上升，说明锁争抢已成瓶颈
IO 线程数不调，再多核也喂不饱
读写线程数默认各为 4，8 核以上服务器基本不够用。InnoDB 的 IO 调度是异步的，但后台线程数量不足时，请求会排队，CPU 空等 I/O 完成，实际利用率上不去。
-
innodb_read_io_threads和innodb_write_io_threads建议设为 8（16 核以下）或 12（32 核以上） - SSD 场景下效果更明显；HDD 上调太高反而可能因寻道混乱降低吞吐
- 需同步检查
Innodb_data_reads/Innodb_data_writes和Innodb_data_pending_reads/Innodb_data_pending_writes，后者持续 > 0 就说明 IO 线程吃紧
thread_cache_size 不够，线程创建就吃掉 10% CPU
当应用使用短连接（比如 HTTP 请求直连 DB），每秒新建销毁线程，Threads_created 每秒增长 > 1，意味着内核在反复做 clone() 和 exit()，这部分开销直接反映在 CPU user 时间里。
-
thread_cache_size建议设为max_connections × 0.1（最低 4，最高 32） - 搭配应用端连接池的
idle_timeout和 MySQL 的wait_timeout（建议统一设为 300 秒） - 别迷信
thread_handling = pool-of-threads：社区版该模式只是模拟，对长事务、复杂 JOIN 易引发死锁，稳定性不如one-thread-per-connection
自旋等待参数调错，CPU 白烧不干活
InnoDB 在获取行锁失败时，默认先自旋 innodb_spin_wait_delay 次（默认 6），再让出 CPU。这个值太小，线程反复抢锁空转；太大，响应延迟拉长。
- 典型表现：top 里 mysqld 占满 CPU，但
SHOW PROCESSLIST中多数线程状态是updating或Locked，且Handler_read_rnd增长缓慢 - 建议从默认 6 开始，按 2 的倍数调整（如 4、8、12），压测 TPS + 平均延迟组合最优值
- 注意：该参数只影响锁争抢路径，对纯 CPU 密集型查询（如 GROUP BY + ORDER BY 大结果集）无效
真正卡住多核扩展性的，往往不是某个单一参数，而是 innodb_spin_wait_delay、innodb_thread_concurrency 和 innodb_adaptive_hash_index 三者之间的协同失效。调参前务必开 performance_schema，用 events_waits_summary_global_by_event_name 查锁等待类型，而不是靠猜。
