MySQL社区版不支持thread_pool插件，仅企业版、Percona Server和MariaDB支持；启用需先验证版本和插件状态，再设thread_handling=pool-of-threads，并合理配置thread_pool_size等参数。
确认 MySQL 版本是否支持 thread_pool 插件
社区版 MySQL（包括 8.0+）压根不带 thread_pool 插件，无论你怎么配 my.cnf 或执行 INSTALL PLUGIN thread_pool SONAME 'thread_pool.so'，都会报错 Plugin 'thread_pool' is not supported。这是你所有配置失效的根源。
必须先验证：执行 SELECT VERSION(), @@version_comment;，输出里得有 Enterprise 或 Commercial 字样；再查 SHOW PLUGINS WHERE PLUGIN_NAME = 'thread_pool';，状态必须是 ACTIVE。Percona Server 和 MariaDB 虽有兼容实现，但插件行为和参数名不完全一致，不能直接套用企业版配置。
thread_handling = pool-of-threads 是硬性开关
即使插件已加载，MySQL 默认仍走 one-thread-per-connection 模式。漏掉这行配置，thread_pool_size 等所有参数全被忽略——你会看到 information_schema.thread_pool_stats 表为空，SHOW PROCESSLIST 里依然堆满 Sleep 线程，以为“开了线程池”，实际根本没生效。
必须在 [mysqld] 段中显式写入：
thread_handling = pool-of-threads
注意：thread_handling 是开关型参数，只接受这两个值，拼错、大小写错误或加空格都会导致启动失败。
thread_pool_size 和 thread_pool_stall_limit 的取值陷阱
这两个参数对短连接场景影响最直接，但调错反而恶化延迟：
-
thread_pool_size不是 CPU 逻辑核数 × 2，而是物理核心数（关闭超线程后的真实核数），8 核服务器设 8～12 即可；超过 16 很少提升吞吐，却会加剧组间调度竞争 -
thread_pool_stall_limit单位是毫秒，但配置时必须带单位（如20ms），默认60ms对毫秒级短查询太宽松，大量小查询会被塞进队列排队；建议压测下调到10ms～20ms，让短查询绕过线程池直连 -
thread_pool_oversubscribe设太高（如 >4）会导致单组内任务堆积，小查询等太久；OLTP 场景保持2～3更稳
thread_pool 解决不了 max_connections 问题
开了线程池，Too many connections 错误照常发生——它只优化已有连接的线程复用效率，不放宽连接上限。
真正要扛住高频短连接，必须同步做三件事：
- 调大
max_connections，但要结合内存算：每连接约占 256KB～1MB，别设到 10000 却只给 2GB 内存 - 大幅缩短
wait_timeout和interactive_timeout（例如设为30），让空闲连接快速释放 - 应用层必须用连接池（如 HikariCP），禁止每次 HTTP 请求都新建 MySQL 连接；否则线程池再高效也救不了连接爆炸
线程池不是银弹，它只在“连接数高 + 查询极短 + CPU 核心足够”这个狭窄窗口里起效；一旦混入长事务或锁等待，调度反而更卡。上线前务必用真实流量压测 Thread_pool_waited 和 Thread_pool_idle_threads 这两个状态变量，别信配置文件里的数字。
