看起来你遇到的是典型的数据库连接池管理和MySQL连接资源耗尽的问题，结合你的配置和错误信息，我来拆解问题根源并给出永久解决方案和最佳实践：

问题根源分析 #

首先，两个错误指向了不同但关联的问题：

• ER_CON_COUNT_ERROR: Too many connections：你的RDS实例max_connections是90，但实际连接数已经打满了——而PROCESSLIST里的40-50个sleep连接是罪魁祸首，这些闲置连接没有被及时回收，占用了宝贵的数据库连接资源。
• TimeoutError: Knex: Timeout acquiring a connection：Knex连接池的max设为20，但要么是池里的连接都被占用（比如未释放的事务或连接泄漏），要么是数据库本身已经没有可用连接，导致新请求拿不到连接超时。

立即修复步骤 #

先快速缓解当前问题：

• 调整MySQL闲置连接超时参数：在AWS RDS的参数组里，修改wait_timeout和interactive_timeout为300秒（5分钟）。这两个参数控制MySQL自动断开闲置连接的时间，默认可能很长（比如8小时），导致sleep连接积累。修改后应用参数组（动态参数无需重启实例，静态参数需要重启）。
• 检查未关闭的事务：事务中的连接会被锁定直到提交/回滚，如果代码里有未处理的事务（比如异常时没回滚），会导致连接一直被占用。确保所有transacting(trx)的操作都在try/catch块里处理，无论成功失败都提交或回滚。
• 临时调整Knex连接池参数：把acquireConnectionTimeout适当延长到15000（15秒），避免在连接池短暂紧张时直接抛出超时错误，但这只是临时措施，不是根本解决办法。

永久解决方案与最佳实践 #

1. 优化连接池配置 #

根据你的RDS max_connections和应用实例数量，合理调整Knex连接池参数：

• 计算每个实例的max连接数：假设你有N个应用实例，每个实例的连接池max应该是(RDS max_connections / N) * 0.7——留30%的余量给管理员连接、系统连接和突发流量。比如如果是2个实例，90/2*0.7≈30，所以把pool.max设为30。
• 降低min连接数：把min设为0或1，避免低负载时保持过多闲置连接，浪费数据库资源。
• 启用闲置连接回收：添加idleTimeoutMillis: 60000（1分钟），让Knex连接池主动回收闲置超过1分钟的连接，归还到数据库。
• 优化后的配置示例：

  knex: {
    client: 'mysql',
    connection: {
      host: 'xxxxxxx.rds.amazonaws.com',
      user: 'xxx',
      password: 'xxxxx',
      database: 'xxxx',
      charset: 'utf8',
      connectTimeout: 10000, // 连接MySQL的超时时间
      timeout: 60000 // 连接闲置超时（传给MySQL）
    },
    debug: true,
    pool: {
      min: 0,
      max: 30, // 根据实例数量调整
      idleTimeoutMillis: 60000, // 1分钟闲置后回收连接
      acquireConnectionTimeout: 15000 // 获取连接的超时时间
    }
  }
  

2. 排查并修复连接泄漏 #

连接泄漏是导致连接池耗尽的常见原因，要确保所有数据库操作都正确释放连接：

• 用async/await处理所有查询：避免直接调用异步方法而不等待，比如：
  ❌ 错误做法：

  // 没有await，连接不会被自动释放
  bookshelf.model('TableA').fetchAll();
  

  ✅ 正确做法：

  await bookshelf.model('TableA').fetchAll();
  

• 严格处理事务：所有事务必须在try/catch块中完成，确保异常时回滚：

  const trx = await bookshelf.transaction();
  try {
    await bookshelf.model('TableA').forge(data).save(null, { transacting: trx });
    await trx.commit();
  } catch (err) {
    await trx.rollback();
    throw err; // 抛出错误以便上层处理
  }
  

• 利用Knex debug日志：你已经开启了debug: true，可以查看日志中acquire connection和release connection的记录，定位是否有只获取不释放的连接。

3. 监控与告警 #

建立监控机制，提前发现问题：

• 监控RDS连接数：在AWS CloudWatch中监控RDS的Connections指标，设置告警阈值（比如达到max_connections的80%时触发告警）。
• 监控应用连接池状态：通过Knex的pool对象暴露连接池状态，比如：

  // 可以在应用的监控端点返回这些数据
  const poolStats = {
    used: knex.pool.numUsed(),
    idle: knex.pool.numIdle(),
    total: knex.pool.numTotal()
  };
  

• 定期检查PROCESSLIST：用SHOW PROCESSLIST查看sleep连接的数量，确保MySQL的超时参数生效，闲置连接被及时回收。

4. 架构层面优化 #

如果流量持续增长，考虑从架构上减轻数据库压力：

• 升级RDS实例：不同实例类型的max_connections不同，比如t3.medium默认有151个连接，比你当前的90多，可以升级实例类型提高连接上限。
• 引入缓存：用Redis缓存频繁查询的结果（比如列表数据、详情数据），减少数据库的连接请求。
• 读写分离：把读请求分流到RDS只读副本，减轻主库的连接压力，同时提高读取性能。

验证步骤 #

修改配置和代码后，按以下步骤验证：

1. 重启应用和RDS实例（如果修改了静态参数）。
2. 模拟高并发请求（比如用Artillery、Postman Runner等工具），观察是否还出现超时和连接数错误。
3. 查看MySQL的PROCESSLIST，确认sleep连接数量在闲置后会减少，不会持续积累。

内容的提问来源于stack exchange，提问作者Mahasooq