MySQL线程池未启用时，innodb_thread_concurrency设为0因过度争锁和上下文切换反而更慢；建议值≈CPU核心数×2，IO线程和自旋参数需协同优化，IO瓶颈下调参无效。
mysql线程池没开，innodb_thread_concurrency设成0反而更慢
MySQL默认不启用线程池（Thread Pool），innodb_thread_concurrency 控制的是InnoDB内部并发线程数，不是连接数。设成0表示“不限制”，但实际在多核CPU上，过多线程争抢锁、频繁上下文切换，反而拖慢响应。
-
innodb_thread_concurrency建议值 ≈ CPU核心数 × 2（仅限高并发OLTP场景；低负载或SSD存储可设为0） - 真正影响多核利用率的是
innodb_read_io_threads和innodb_write_io_threads，它们控制后台IO线程数，默认各4，8核以上建议调到8甚至12 - 必须配合
innodb_adaptive_hash_index = OFF（尤其5.7+版本），否则高并发下哈希索引自适应逻辑会成为CPU热点
连接数爆满时，thread_handling = pool-of-threads 不是万能解
MySQL官方线程池插件（thread_pool）只在企业版提供；社区版的 pool-of-threads 是模拟实现，仅适用于短连接高频查询场景，对长事务或复杂JOIN几乎无效，还可能引发死锁。
- 社区版更稳妥的做法是：用连接池（如ProxySQL、HAProxy）做连接复用，把
max_connections控制在200–500之间，避免内核级线程创建开销 - 检查
Threads_created状态变量，若每秒增长 > 1，说明连接反复创建销毁，此时调大wait_timeout和应用端连接池 idle timeout 更有效 -
thread_handling = one-thread-per-connection在现代Linux + epoll下其实比模拟线程池更稳定，别迷信“pool”字眼
innodb_spin_wait_delay 调太小，CPU空转反而吃满
InnoDB在获取行锁/表锁失败时会先自旋等待，而不是立刻让出CPU。innodb_spin_wait_delay 控制每次自旋的循环次数，默认6，数值过小会导致大量线程反复尝试、抢CPU；过大则延迟响应。
- 物理CPU超线程开启时（如16核32线程），建议设为12–24；纯物理核（如8核8线程）设为6–12即可
- 搭配
innodb_spin_wait_pause_multiplier = 50（默认50），避免自旋期间过度占用缓存带宽 - 观察
SHOW ENGINE INNODB STATUS中的spin waits和rounds比值：若 rounds/spin waits > 1000，说明自旋效率极低，该降低 delay 或检查锁争用热点
查sys.schema_table_statistics发现io_read_requests飙升，但CPU没跑满？
这通常意味着IO瓶颈掩盖了CPU潜力——即使开了多核，磁盘吞吐跟不上，线程全卡在等待IO返回，CPU自然闲置。优化方向不在并发参数，而在IO路径。
- 确认是否用了
innodb_flush_method = O_DIRECT（Linux下必须，避免双缓冲） -
innodb_log_file_size太小（如默认48MB）会导致频繁checkpoint，增大到1G–2G（需停机调整）能显著减少日志刷盘压力 - 用
iostat -x 1观察%util和await：若 %util 接近100% 且 await > 10ms，说明磁盘已饱和，加CPU核心无意义
多核性能释放的前提是IO和锁竞争不成为瓶颈，参数调得再细，硬盘慢、索引乱、事务长，CPU就只能干等。最常被跳过的其实是 EXPLAIN FORMAT=JSON 里看 executors 和 index_condition_pushdown 是否生效——这些比改 innodb_thread_concurrency 影响更大。
