连接数规划是数据库容量设计中容易被忽视的一环。不少团队在压测时发现接口响应变慢，第一反应是加机器、加缓存，最后排查半天才发现是数据库连接数打满导致的。连接数不是越大越好，也不是越小越安全，它需要根据业务流量特征、数据库实例规格和应用部署结构综合评估。这篇文章结合实际生产经验，讲清楚连接数的计算逻辑和配置方法。
先搞清楚：一个数据库连接到底有多重
很多人对连接数没有概念，觉得一个连接就是一条逻辑链路，成本可以忽略。实际上，在MySQL这类数据库中，每建立一个连接，服务端都要分配独立的资源。首先是线程资源，MySQL默认采用 thread-per-connection 模型，每个连接对应一个线程，线程栈默认在256KB到512KB左右。其次是内存缓冲区，每个连接会分配 sort_buffer_size、join_buffer_size、read_buffer_size 等会话级缓冲区，这些缓冲区只在需要时分配，但在高并发下会被频繁触发。如果一个连接执行排序时用满了 sort_buffer_size，几个缓冲区叠加起来，单个连接的内存占用轻松超过1MB。
假设一台16GB内存的数据库服务器，扣除系统、InnoDB缓冲池和其他常驻内存，留给连接的内存大约只有几个GB。如果每个连接峰值占用2MB，理论上限也就是1500个左右连接。所以把 max_connections 设成10000不但没有意义，反而会让数据库在线程调度和内存分配上先崩溃。正确的思路是：连接数上限应该由数据库可用内存除以单连接平均内存开销来推导，而不是拍脑袋给一个大数。
另外要注意连接建立本身的成本。TCP三次握手、数据库认证、权限校验、分配线程，这一套流程在高压下可能耗时几毫秒到几十毫秒。如果应用不做连接复用，每个请求都新建连接再销毁，数据库的大部分CPU会消耗在连接管理上，而不是执行SQL。这就是为什么生产环境必须使用连接池的原因。
连接池参数怎么算：最小、最大、超时
应用侧的连接池是连接数规划的核心。常见的连接池有Java生态的HikariCP、Druid，Go语言的database/sql配合配置，以及各类框架内置的池。无论哪种实现，关键参数都是三个：最小空闲连接数、最大连接数、获取连接的超时时间。
最大连接数的经典估算公式是：最大连接数 = 核心线程数 × 单线程并发请求数 × 实例数 × 冗余系数。举个例子，一个服务部署了8个实例，每个实例配置最大连接20，那么这个服务对数据库的峰值连接需求就是160。如果同一个数据库上还有其他服务，需要把所有服务的需求加总，再对比数据库的 max_connections，留出20%到30%的余量给运维操作、定时任务和监控探针使用。
单实例最大连接数怎么定？经验做法是参考数据库的CPU核数。数据库真正并行执行SQL的能力受限于CPU，一个32核的数据库实例，活跃连接数超过100后，大量连接只是在排队等CPU。所以应用侧单个实例的最大连接数通常设置在10到50之间，通过增加应用实例来水平扩展总连接数，比把单实例连接池调大更合理。超时时间方面，获取连接的等待超时建议设置在几百毫秒到1秒，让失败的请求快速失败并触发熔断，而不是无限等待把应用线程拖死。下面是一个HikariCP的典型配置：
HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://192.168.0.10:3306/order_db");
config.setUsername("app_user");
config.setPassword("secret");
// 最小空闲连接，保持少量常连接避免冷启动开销
config.setMinimumIdle(10);
// 单实例最大连接数，按实例数量反推数据库总压力
config.setMaximumPoolSize(30);
// 获取连接超时，快速失败交给上层熔断处理
config.setConnectionTimeout(800);
// 连接最大存活时间，防止连接被数据库单方面断开
config.setMaxLifetime(1800000);
// 空闲连接回收时间
config.setIdleTimeout(600000);
还有两个容易被忽略的细节。一是 maxLifetime 要小于数据库的 wait_timeout 或中间件的连接空闲回收时间，否则会出现应用拿着一个已被数据库断开的死连接去执行SQL，报出奇怪的通信异常。二是连接池中不要开启自动提交后长期占用连接，执行完业务逻辑尽快归还，把持连接做大计算是连接耗尽的常见原因。
高并发下的隐患：连接数为什么总是不够用
按公式算好的连接数，上线后还是经常报获取连接超时，问题往往不在配置，而在SQL本身的执行状况。第一个元凶是慢查询。一条SQL本来10毫秒执行完，因为缺索引变成了3秒，连接被占住的时间放大300倍，连接池吞吐直接坍塌。这种情况下盲目调大连接数没用，必须先治理慢SQL。建议开启慢查询日志，把执行时间超过500毫秒的SQL抓出来逐个优化。
第二个是长事务和锁等待。一个事务开启后长时间不提交，不仅占着一个连接不放，还可能持有锁让其他事务的连接阻塞等待，形成连接占用连锁反应。排查时可以通过 information_schema.innodb_trx 表查看运行时间过长的事务，通过 SHOW PROCESSLIST 查看当前连接状态，大量处于 Waiting for table metadata lock 或 Sending data 状态的连接就是治理对象。
第三个是突发流量下的重试风暴。上游超时后触发重试，多个重试请求叠加，连接需求瞬间翻倍。解决办法是在网关或客户端做重试预算控制，配合信号量隔离，限制对数据库访问的并发上限，宁可让部分请求被限流拒绝，也不要让数据库被拖垮后全军覆没。监控方面，重点观察三个指标：当前连接数与最大连接数的比值、连接池获取连接的等待时长分布、Threads_running 与连接总数的比值。如果连接数很高但 Threads_running 很低，说明大量连接在空闲或排队，这时该优化的是SQL而不是加连接。
总结一下规划思路：先算数据库侧的内存承受能力得到 max_connections 上限，再按应用实例数反推单实例连接池大小，配置时保持所有应用池的总和加上余量不超过数据库上限，最后通过慢SQL治理、事务时长控制和监控告警来保证连接数长期健康。连接数规划不是一次性的配置动作，而是随流量增长持续调整的动态过程。