查 INFORMATION_SCHEMA.PROCESSLIST 可实时监控连接与线程状态，聚焦非 Sleep 连接、TIME 持续增长及 STATE 异常；结合 SHOW STATUS 的 Threads_connected/running/created 判断线程池实效；thread_pool_size 需匹配 CPU 与业务特征，避免过大引发上下文切换；max_connections 和 wait_timeout 仍须严格管控，线程池不解决锁争用或连接泄漏。
查 INFORMATION_SCHEMA.PROCESSLIST 看实时连接与线程状态
MySQL 的每个客户端连接都会对应一个线程（哪怕启用了线程池），PROCESSLIST 是最直接的观察入口。它不反映线程池内部调度，但能告诉你「当前谁在跑、卡在哪、是不是真并发」。
常见错误现象：State 长期为 Sending data 或 Locked，但 Command 是 Query，说明查询本身没卡在连接层，而是执行慢或锁等待；若大量 Sleep 连接堆积，说明应用没正确复用连接，和线程池效率无关，先查连接池配置或应用代码。
-
SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND != 'Sleep';—— 排除空闲连接，聚焦活跃负载 - 注意
ID和TIME：TIME > 0 且持续增长，大概率是慢查询或锁等待，不是线程池问题 -
STATE为空或NULL时，该线程可能刚创建/正销毁，别误判为阻塞
用 SHOW STATUS LIKE 'Thread%' 判断线程池是否真起效
线程池插件（如 thread_pool）启用后，并不会让 Threads_created 归零，但会显著压低它的增长速率。关键看三个指标的联动关系：
-
Threads_connected：当前打开的连接数（应用层视角） -
Threads_running：真正执行 SQL 的线程数（内核实际并发度） -
Threads_created：自启动以来新建线程总数（越低越好，说明线程复用充分）
如果 Threads_connected 经常几百，但 Threads_running 峰值只有 10–20，且 Threads_created 每小时只增个位数，说明线程池调度正常；反之，若 Threads_created 每秒都在涨，基本等于线程池没生效——检查是否漏配 thread_pool_size 或插件根本没加载。
thread_pool_size 设太小反而拖慢高并发短查询
这个参数控制线程池中「可并行执行任务的线程上限」，不是越大越好，也不是越小越省资源。它影响的是「同一时刻最多几个 SQL 在 CPU 上跑」，而非连接数。
使用场景：OLTP 类短查询（平均执行 500）时，thread_pool_size 过小会导致任务排队，STATE 显示 Waiting in thread pool queue（注意：这不是标准 MySQL 状态，需开启 thread_pool_stats 表或查错误日志确认）。
- 默认值 16，对多数中小业务够用；超 1000 QPS 且延迟敏感，可试调到 32–64
- 设超过 CPU 核心数 × 2 容易引发上下文切换开销，实测收益反降
- 调整后必须配合监控
thread_pool_idle_threads和thread_pool_waited（如有）判断排队情况
线程池下 max_connections 和 wait_timeout 仍要严控
线程池管的是「执行资源」，不是「连接资源」。连接数爆掉照样 OOM，只是崩溃前多一层排队缓冲而已。
容易踩的坑：以为开了线程池就不用管连接泄漏，结果 Threads_connected 持续上涨，最终触发 max_connections 限制，新连接被拒，而老连接还在池里排队——此时 SHOW PROCESSLIST 看不到异常，但应用报错全是 Too many connections。
-
wait_timeout建议设为 60–180 秒，避免空闲连接长期占着Threads_connected名额 -
max_connections不应盲目调大，需按应用最大连接池 size × 实例数 × 1.2 预留，再加监控告警 - 线程池无法缓解表锁、MDL 锁等导致的「假活跃」连接，这类连接在
PROCESSLIST中State为Waiting for table metadata lock，得从 SQL 优化或事务拆分入手
线程池的并发效率，本质上是个「排队系统」的调优问题：连不上是前端配置问题，排不上队是 thread_pool_size 或锁争用问题，跑不动是 SQL 或硬件瓶颈。别指望一个参数解决所有吞吐问题。
