连接数过高主因是应用层连接使用不当，包括连接池配置不合理、SQL执行慢、事务未及时释放及缺乏并发控制；应按峰值活跃连接的1.2–1.5倍设maxPoolSize，启用泄漏检测，优化慢SQL与事务边界，并结合限流降级与监控告警。
连接数过高通常不是数据库本身的问题，而是应用层连接使用不当导致的。核心在于连接池配置不合理、SQL执行慢、事务未及时释放，或缺乏并发控制机制。
连接池配置是否匹配实际负载
连接池最大连接数（maxPoolSize）设得过高，会导致大量空闲连接堆积；设得太低，则请求排队等待，拖慢响应甚至触发超时。关键要看平均并发请求数、单次SQL耗时、以及业务流量峰谷比。
- 观察生产环境实际活跃连接数（如 MySQL 的 SHOW STATUS LIKE 'Threads_connected'），建议 maxPoolSize 设为峰值活跃连接的 1.2–1.5 倍
- 启用连接泄漏检测（如 HikariCP 的 leakDetectionThreshold），及时发现未 close() 的 Connection
- 设置合理的连接超时（connectionTimeout）和空闲连接回收时间（idleTimeout），避免长期闲置连接占用资源
慢 SQL 和长事务是隐形连接杀手
一条执行 5 秒的查询，会独占一个连接 5 秒；若并发 100，就可能瞬间占满 100 个连接。事务未提交更危险——连接会一直被持有，直到事务结束或超时回滚。
- 定期分析慢查询日志，重点优化 WHERE 条件无索引、JOIN 多表未走驱动表、ORDER BY + LIMIT 深分页等典型场景
- 在应用中严格控制事务边界，避免在事务内调用外部服务或执行耗时操作
- 对读多写少场景，考虑用 READ COMMITTED 隔离级别替代默认的 REPEATABLE READ，减少锁持有时间
用限流与降级应对突发流量
即使连接池调优到位，突发流量仍可能打爆连接数。需在应用网关或服务入口做前置控制。
- 在 API 网关（如 Spring Cloud Gateway）或微服务框架（如 Sentinel）中配置 QPS 限流，拒绝超额请求而非让其排队争抢连接
- 对非核心接口（如报表导出、批量同步）增加熔断逻辑，连接池获取失败时快速返回友好提示，不重试不阻塞主线程
- 数据库侧可配置 max_connections 上限并配合 wait_timeout 缩短空闲连接生命周期，防止连接长期滞留
监控与告警必须落地到具体指标
光看“连接数高”没意义，要结合上下文判断是否异常。重点关注三类指标联动分析：
- 活跃连接数 / 最大连接数 > 80% 且持续 5 分钟以上 → 触发告警
- 连接池中 pending acquisition（等待获取连接的线程数）持续增长 → 表明获取连接成为瓶颈
- 数据库 Threads_running 显著高于 Threads_connected → 说明大量连接正在执行 SQL，需查慢查询
