等待连接并不必然意味着连接池太小。长事务、未及时释放、慢查询或请求突增，都可能让连接长期占用。直接提高上限会把更多并发推向数据库，可能使整体更慢。
先区分拿连接慢和执行慢
记录连接等待、语句耗时和事务持续时间，检查并发请求在做什么。若大量连接被少数长事务占用，应先处理占用原因，而不是只扩大可连接数量。
计算所有实例的总需求
每个副本各自拥有连接池时，扩容会改变总连接压力。还要计入后台任务、管理工具和其他应用。单个服务配置看起来合理，不代表数据库能够承受所有使用方的峰值。
缩短不必要的持有时间
避免在持有数据库事务时等待用户交互、慢远程调用或长计算。按框架要求管理上下文与连接生命周期，确保异常与取消路径也能释放资源。具体调整应保护业务一致性。
验收稳定并发而非瞬时峰值
观察连接数、排队、错误和数据库负载能否在目标压力下稳定。若提高上限只是把等待从应用搬到数据库，不能视为问题解决。
常见问题：使用连接池后还需要释放连接吗？
需要遵循客户端的释放约定，让连接能够回到池中复用；池不会替应用纠正所有生命周期错误。
技术参考：微软：EF Core 高效查询。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的团队正遇到类似问题，可以从一条关键业务路径开始，整理现状、证据与约束，通过系统架构诊断明确优先级、候选方案和验证范围。