连接数过高主因是应用层连接使用不当，包括连接池配置不合理、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，需查慢查询