线程池管数据库服务端执行SQL的线程，连接池管客户端到数据库的Connection逻辑通路；前者限并发执行数防资源过载，后者控连接生命周期防建连风暴；需协同配置并联动监控。
线程池和连接池都用“池”字，但管的不是一回事：一个管服务器端的执行单元（线程），一个管客户端到数据库的通信通道（连接）。搞混了容易在高并发时踩坑——比如连接池设得很大，但MySQL线程池没开，结果所有连接挤在同一堆线程里排队，DB照样卡死。
管的对象完全不同
连接池管理的是Connection对象，本质是客户端与数据库之间的一条逻辑通路，背后涉及TCP建连、身份认证、权限校验等开销。它通常部署在应用层（如Java里的HikariCP、Druid），由业务代码显式获取、使用、归还。
线程池管理的是Thread对象，是数据库服务端用来执行SQL的实际工作单元。MySQL企业版或Percona Server才内置线程池插件，社区版默认是“每连接一线程”（one-thread-per-connection）模式，连接数一多，线程数就爆炸。
设计目标和控制粒度不同
连接池关注连接生命周期效率：
- 最小空闲连接数保障低峰期快速响应
- 最大连接数防应用侧打爆数据库连接上限
- 但归还连接不等于释放线程——连接空闲了，对应线程可能还在跑其他查询
线程池关注服务端资源饱和控制：
- 固定一组线程轮询处理多个连接的请求
- 限制同时执行的SQL数量，避免CPU、内存、锁竞争过载
- 即使有1000个连接，线程池只允许最多32个并发执行，其余排队等待
失效机制和健康检查方式不同
连接池必须主动验证连接有效性：
- 通过testOnBorrow/testWhileIdle执行SELECT 1或ping检测
- 超时连接、网络中断、数据库重启后失效的连接要剔除
- 否则应用拿到“假连接”，报CommunicationsException
线程池一般不“检测线程健康”，而是靠系统级调度：
- 线程崩溃会触发异常捕获和重建
- 长期阻塞（如锁等待）由数据库自身超时机制（wait_timeout、innodb_lock_wait_timeout）终止
- 线程本身没有“空闲/活跃”状态切换，只有“运行中”或“等待任务”
为什么建议两者配合使用
单靠连接池只能缓解客户端开销，压不住DB服务端压力；单靠线程池又无法解决应用频繁建连的问题。真实生产环境常见组合：
- 应用层配HikariCP：maxPoolSize=20，minIdle=5，connection-timeout=30s
- MySQL服务端启用thread_pool_size=16（参考CPU核心数×2）
- 监控指标联动：当Threads_running持续＞12且连接池等待数上升，说明线程池已成瓶颈，需调参或优化慢SQL
不复杂但容易忽略
