thread_pool_size应设为cpu逻辑核心数（如16核设16），短查询多可试20，超32在oltp中通常无收益；需避坑物理核×2配置、容器中误读topology，且须同步调优max_connections与thread_pool_stall_limit。
thread_pool_size 设多少才不翻车
它不是并发连接数上限，而是线程组数量。每个组独立调度请求，组内线程复用。设太高反而引发 THREAD_POOL_WAIT_GROUP_LOCK 等锁争用，拖慢整体响应。
安全起点是等于 CPU 逻辑核心数（lscpu | grep "CPU(s)" 看到的 “CPU(s)” 值，不是超线程总数）。例如 16 核服务器，thread_pool_size = 16 是合理起始值；若短查询占比高（如 API 接口），可试 20；但超过 32 在多数 OLTP 场景下已无收益。
容易踩的坑：
- 直接按物理核数 ×2 设置（如 32 核配 64），压测后发现
Threads_running长期 > 5 且thread_pool_idle_threads持续为 0，说明组内调度过载 - 在容器或虚拟机中未暴露真实 topology，
lscpu显示的 core(s) per socket ≠ 可用并发能力，需结合cat /sys/fs/cgroup/cpu.max或docker inspect核实可用 vCPU
thread_pool_stall_limit 怎么避免误判“卡住”
这个值决定 MySQL 多久没响应就算“stall”，进而触发线程迁移。设太低（如 10000，即 10ms）会让简单索引查询也被踢出当前组，频繁上下文切换；设太高（如 1000000）则长事务或锁等待无法及时让出，拖垮整个组。
推荐配置：
- 纯 OLTP（95% 查询 thread_pool_stall_limit = 60000（60ms）
- 混合负载含报表类查询：
thread_pool_stall_limit = 200000（200ms），并配合max_execution_time控制单条语句时长
必须监控 SHOW STATUS LIKE 'Thread_pool_stalled_threads'：持续 > 0 表示阈值不合理。
启用 thread_handling=pool-of-threads 后连接还是打满？
线程池只改调度方式，不放宽连接硬限。max_connections 仍是第一道闸门。常见误判是以为开了线程池就“自动扩容”，结果客户端仍报 ERROR 1040 (HY000): Too many connections。
真正要调的组合是：
- 确保
max_connections足够（如1000+），否则连不上 - 检查
open_files_limit≥max_connections × 3（CentOS 7 默认 1024，不够会触发Can't create thread） - 确认
thread_pool_max_threads没被误配成极低值（默认不限制，但有人设为32导致高并发下请求排队） -
thread_cache_size对线程池模式基本无效——它只影响传统 one-thread-per-connection 模式
为什么监控 Thread_pool_idle_threads 比看 Threads_connected 更关键
Threads_connected 只告诉你有多少连接活着，而 thread_pool_idle_threads 才反映线程池是否真有余力处理新请求。它代表当前空闲、可立即调度的线程数（注意：不是“空闲连接”，是空闲工作线程）。
如果该值长期为 0，哪怕 Threads_connected 只有 200，也说明线程组已饱和，新请求正在排队等调度；反之，若它稳定在 5–10，说明池子健康。
复杂点在于：这个指标受 thread_pool_size 和 thread_pool_stall_limit 共同影响，单独调一个参数看不出效果。必须搭配 Thread_pool_waited_threads 和 Thread_pool_stalled_threads 一起看，才能定位是调度策略问题，还是资源真的不足。
