线程池大小需按任务类型配置：CPU密集型设为CPU核心数+1，I/O密集型设为CPU核心数的2–4倍或按公式CPU核数×(1+等待时间/计算时间)估算，并结合监控与压测持续调优。
thread_pool_size 设多少才不翻车
线程池不是开得越多越好，thread_pool_size设高了反而会因调度锁争用拖慢整体响应。它代表线程组数量，每个组独立调度连接请求，理想值应接近 CPU 逻辑核心数（非超线程总数）。比如 16 核 CPU，设 thread_pool_size = 16 是安全起点；若负载以短查询为主（如 API 接口），可试 20；但超过 32 在多数 OLTP 场景下已无收益，反而增加 THREAD_POOL_WAIT_GROUP_LOCK 等等待事件。
容易踩的坑：
- 直接按物理核数 ×2 设置（如 32 核设 64），实际压测后发现
Threads_running长期 > 5 且thread_pool_idle_threads持续为 0，说明组内调度过载 - 在虚拟机或容器中未暴露真实 CPU topology，
lscpu显示的 core(s) per socket 不等于可用并发能力，需结合cat /sys/fs/cgroup/cpu.max或docker inspect核实
thread_pool_stall_limit 怎么避免误判“卡住”
thread_pool_stall_limit 是线程池判断一个请求是否“阻塞”的微秒阈值，它直接影响请求是否被踢出当前线程组、转交其他组处理。设太低（如 10000，即 10ms）会导致简单索引查询也被标记 stall，引发频繁线程迁移和上下文切换；设太高（如 1000000）则长事务或锁等待无法及时调度让出，拖垮整个组。
推荐做法：
- OLTP 主流业务（95% 查询 thread_pool_stall_limit = 60000（60ms）
- 混合负载含报表类查询：设
200000（200ms），并配合max_execution_time控制单条语句时长 - 必须监控
SHOW STATUS LIKE 'Thread_pool_%'中的Thread_pool_stalled_threads，持续 > 0 表示阈值不合理
为什么 thread_handling=pool-of-threads 启用后连接数还是打满
启用线程池只是改变了线程复用方式，并不自动放宽连接上限。max_connections 仍是硬门槛，而 thread_cache_size 对线程池模式基本无效——因为线程池里没有“缓存线程”概念，只有“空闲线程”（thread_pool_idle_threads）。
真正要调的组合是：
- 确保
max_connections足够（如 1000+），否则客户端连不上，报错ERROR 1040 (HY000): Too many connections - 检查
open_files_limit是否 ≥max_connections × 3，CentOS 7 默认 1024，不够会触发Can't create thread错误 - 确认
thread_pool_max_threads没被意外压到极低值（默认不限制，但有人误配为 32 导致高并发下请求排队） - 观察
Threads_connected和Threads_running差值：若长期 > 500，说明大量连接空闲却无法释放，可能是应用端没正确 close，或wait_timeout过大（建议设 60–120）
线程池 + 连接池中间件怎么配才不互相打架
线程池管的是 MySQL 内部工作线程，连接池（如 HikariCP、Druid）管的是应用到 MySQL 的 TCP 连接。两者叠加时，最容易出问题是连接池最大连接数远超线程池吞吐能力，导致大量连接排队等待线程服务，表现为平均响应时间陡增、P99 毛刺严重。
协调要点：
- 连接池
maximumPoolSize建议 ≤thread_pool_size × 4（例如线程池 16 组 → 连接池最多 64），留出余量应对突发 - 禁用连接池的“连接测试”类操作（如
connectionTestQuery），这类短频查询会高频触发线程组调度，放大thread_pool_wait_group_lock开销 - MySQL 侧开启
log_slow_admin_statements = ON，捕获类似/* ApplicationName=HikariCP */ SELECT 1的心跳语句，它们在线程池下也会计入 stall 判断
线程池的调度粒度很细，但对慢日志、锁等待、网络延迟这些外部因素完全无感知。调参前务必先确认慢查询是否已收敛、主从复制是否延迟、磁盘 I/O 是否饱和——否则再好的线程池配置也只是在堵漏。
