连接池与线程缓存

做的事：真实连续开关50次连接，对比线程创建数

代码SHOW VARIABLES LIKE 'thread_cache_size'; -- 真实是9 SHOW STATUS LIKE 'Threads_created'; -- 记下基线 -- 真实串行地连接50次，每次都立即断开 for i in 1..50: mysql -u root -e "SELECT 1;"

验证：50次串行连接，真实一个新线程都没创建

实测 · 本机执行输出

连接前：  Threads_created=2   Connections=916
连接后：  Threads_created=2   Connections=967   ← 真实Connections涨了51，Threads_created真实一动没动

50次真实串行的"连接→查询→断开"，Threads_created真实完全没有增加——每次断开连接时，对应的OS线程真实没有被销毁，而是被放进了线程缓存池；下一次新连接来的时候，真实直接从缓存里捞一个现成的线程复用，省掉了真实创建/销毁OS线程的开销。

验证：真实同时开15个并发连接，缓存不够用了

代码-- 真实同时(并发)发起15个连接，超过thread_cache_size=9 for i in 1..15: (mysql -u root -e "SELECT SLEEP(1);" &) wait

实测 · 本机执行输出

Threads_created: 15   ← 真实立刻涨了13（从2到15）

这15个连接真实是同时发起的，缓存里最多只有9个空闲线程可以复用，超出的部分真实必须创建全新的OS线程——thread_cache_size真实只对"串行的连接复用"起作用(A断开之后B再连上，可以复用A留下的线程)，对"真实同一时刻需要的并发连接数超过缓存大小"这种情况完全无能为力，这时候操作系统级别真实的线程创建开销就没法避免了。这也是为什么应用层连接池(在应用进程里长期持有一批数据库连接，不用就等着，而不是每次用完就断开)通常比单纯依赖MySQL自己的线程缓存更有效——真实的开销大头不只是创建线程，还包括每次新连接的权限校验、会话初始化这些真实也要重新走一遍的步骤。

分步演示：串行复用 vs 并发超载，线程创建数的真实对比

每一步都是本文上面用真实的连接压力测试跑出来的原始结果。

串行连接近乎免费，真实并发洪峰才是真开销

这一步新验证的连接模式

本文用到的工具

本机 MySQL 26.7.0（InnoDB），真实的50次串行连接 + 15个并发连接对比
thread_cache_size + Threads_created状态变量

下一篇 · MYSQL / INNODB 115

在线 DDL 与元数据锁