你的网站偶尔报错“数据库连接超时”，重启应用就好了。过几天又来了。你查了数据库，CPU不高，内存够用，慢查询也没几条。重启治标不治本。
问题可能不在数据库，在连接池。连接池是应用和数据库之间的“通道管理器”，配错了，通道堵了，连接就超时了。
连接池是什么？
每次应用程序访问数据库，都要经历一个过程：TCP三次握手、数据库认证、执行SQL、关闭连接、TCP四次挥手。这一套流程走完，真正执行SQL的时间只占一小部分，大部分时间浪费在“建立”和“销毁”连接上。
连接池就是解决这个问题的。它在应用启动时预先创建一批数据库连接，放在池子里。应用程序需要访问数据库时，从池子里拿一个现成的连接用，用完放回去，而不是关闭。
换个说法：没有连接池，就像每次做饭都要去买菜、洗菜、切菜、炒菜，做完扔掉厨具。有连接池，就像提前把菜备好放在冰箱里，做饭时直接拿食材下锅。前者每次重复劳动，后者一次准备，多次使用。
连接池的优势：减少创建和销毁连接的开销，提升响应速度；控制连接数量，避免资源浪费；统一管理连接，防止应用忘记关闭导致连接泄漏。
为什么会出现“连接超时”？
“连接超时”的本质是：应用需要连接时，连接池拿不出来。
典型原因一：连接池满了
连接池有最大连接数限制。如果你的应用并发请求量超过了最大连接数，新的请求拿不到连接，就会超时等待。
text
错误信息：Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
如果一个连接池里有10个连接，同时有15个请求在访问数据库，后5个请求就要等前面的请求用完释放连接。如果前面的SQL执行慢，释放得也慢，后面的请求就超时了。
典型原因二：连接泄漏
应用程序拿了连接，用完没放回池子里。连接一直处于“使用中”状态，池子里的可用连接越来越少，最终耗尽。
典型原因三：连接池配置不当
一些关键配置参数需要根据你的业务场景调整：
| 参数 | 含义 | 常见问题 |
|---|---|---|
minimum_pool_size | 池子最少保留几个连接 | 设太小，突发流量时来不及创建新连接 |
maximum_pool_size | 池子最多能有多少连接 | 设太小，连接用完；设太大，浪费数据库资源 |
connection_timeout | 获取连接的等待时间 | 设太短，高峰期正常排队也会超时 |
idle_timeout | 连接空闲多久被回收 | 设太长，空闲连接占用资源 |
排查步骤
第一步：确认错误类型
查看应用日志，区分两种超时：
- 连接超时：应用从连接池获取连接时超时（通常是连接池满了）
- 查询超时：应用已拿到连接，但SQL执行超过指定时间
SqlConnection.Open出错是连接超时，SqlCommand.ExecuteScalar出错是查询超时。
第二步：查看连接池使用情况
大多数应用框架（Spring Boot、Django、Entity Framework等）都提供连接池监控接口，可以查看当前活跃连接数、空闲连接数、等待线程数等指标。
第三步：检查SQL执行时间
如果连接池经常满，很多时候是因为SQL执行慢，导致连接被长时间占用，释放不及时。配合慢查询日志，找出需要优化的SQL。
第四步：检查代码中是否正确释放连接
using语句（C#）、try-with-resources（Java）、with（Python）可以确保连接用完后自动归还。如果手动管理连接，务必在finally块中关闭。
一个真实案例
一个Spring Boot应用，偶尔报“连接超时”。排查发现，连接池最大连接数设置为30，某个接口在一次请求中执行了多次数据库查询，每次查询耗时500ms，高峰期并发时所有连接被占满。把最大连接数从30调到50，并优化了那个接口的查询逻辑，问题解决。
最后一句
连接池是应用和数据库之间的通道。配置过小、SQL执行慢、连接泄漏，都会导致通道堵塞。调整连接池参数和优化SQL，是解决“连接超时”最常见的手段。如果你碰到了连接超时，先用监控确认连接池是否满了，再查SQL执行时间。
你的连接池满了，通常不是因为数据库扛不住，而是应用使用连接的方式有待优化。