thread_pool_size应按负载特征设定：纯短查询为CPU核数1–1.5倍，混合负载取核数，偶发长查询可略高但需同步调大thread_pool_stall_limit；必须确认插件已安装且thread_handling设为pool-of-threads。
thread_pool_size 设多少才不翻车
线程池不是开得越大越好，thread_pool_size设错反而会加剧锁争用、拖慢响应。它代表线程组数量，不是总工作线程数——每个组内部仍需调度多个连接请求。
常见错误是直接按 CPU 核心数照搬：16 核就设 16，结果在 OLTP 场景下 Threads_running 长期卡在 20+，但实际吞吐没提升。真实推荐值取决于负载特征：
- 纯短查询（平均 5k）：设为 CPU 核心数的 1–1.5 倍，比如 16 核配
thread_pool_size = 12 - 混合负载（含中等复杂查询，如带 JOIN 或 ORDER BY 的分页）：设为 CPU 核心数，比如 16 核配
thread_pool_size = 16 - 偶发长查询（如报表导出）：可略高于核心数（如 16 核配 20），但必须同步调大
thread_pool_stall_limit，否则会被误判为 stall 导致调度失衡
注意：社区版 MySQL 8.0 默认不带 thread_pool 插件，必须确认已安装（INSTALL PLUGIN thread_pool SONAME 'thread_pool.so'）且 thread_handling 已设为 pool-of-threads，否则所有配置无效。
thread_pool_stall_limit 怎么避坑
thread_pool_stall_limit 是线程池最易被忽视的“开关型”参数。它以微秒为单位，定义一个查询多长时间未返回就被标记为 “stall”，从而触发线程重调度。设得太低，短事务频繁被踢出线程组，上下文切换暴涨；设得太高，长查询霸占线程导致其他连接饿死。
典型错误现象：SHOW STATUS LIKE 'Thread_pool%' 中 Thread_pool_stalls 每分钟涨几十次，同时 Threads_running 波动剧烈、Handler_read_rnd_next 暴增——这往往是 stall_limit 被压穿的信号。
- OLTP 主站（95% 查询 thread_pool_stall_limit = 60000（60ms）
- 读写混合系统（含分页/聚合）：建议
thread_pool_stall_limit = 200000（200ms） - 明确区分 OLAP 查询：不要靠调这个参数硬扛，应走专用账号 +
max_execution_time限流，避免污染线程池
该值不能动态 SET GLOBAL 生效，必须写入配置文件并重启 MySQL —— 这点常被忽略，改完不重启等于没改。
为什么 thread_pool_max_threads 很少需要动
thread_pool_max_threads 是线程池能创建的最大线程总数，但它不是性能杠杆，而是安全阀。默认值（通常 64 或 128）对绝大多数场景已足够，盲目调高反而可能触发 OS 级限制或内存 OOM。
真正该盯的是它的实际使用水位：SHOW STATUS LIKE 'Thread_pool_max_threads' 和 Thread_pool_idle_threads 的差值。如果长期 Thread_pool_idle_threads == 0 且 Threads_connected > 3 * thread_pool_size，说明线程组调度已饱和，此时优先检查 SQL 效率和索引，而不是加线程。
- 当
Thread_pool_max_threads_reached状态值非零，才表明真触顶了——这时先看是否max_connections过高、应用端连接泄漏 - 若确需扩容，建议每次只 +16，同时监控
innodb_row_lock_waits是否同步上升（线程增多可能放大锁冲突） - 永远不要把
thread_pool_max_threads设成远大于max_connections / thread_pool_size，例如 500 连接配thread_pool_size=16，设 256 就明显冗余
线程池生效后必须盯住的三个状态值
启用线程池后，光看 Threads_connected 和 Threads_running 不够。这三个状态变量才是判断调度是否健康的“听诊器”：
-
Thread_pool_idle_threads：空闲线程数。健康值应在thread_pool_size的 20%~50% 浮动；持续为 0 表示调度过载，持续 >80% 表示配置过大或流量不足 -
Thread_pool_waited：因线程组忙而排队等待的连接次数。突增意味着线程组处理能力已达瓶颈，需结合慢查日志定位具体 SQL -
Thread_pool_stalls：被标记为 stall 的查询数。>5 次/分钟就要警惕，>20 次/分钟基本确认stall_limit或查询本身有问题
这些值无法持久化，每次重启归零，所以必须接入监控（如 Prometheus + mysqld_exporter），否则等于没开线程池——你根本不知道它是不是在默默失效。
