让我逐个帮你拆解这些连接池和RDS的核心问题，搞懂背后的机制才能合理配置，避免扩容踩坑：

1. 若10位用户同时执行操作，连接池中会生成10个连接吗？释放后连接数是否会归零？ #

首先得提一下：如果你没有显式设置connectionLimit参数，mysql连接池的默认上限是10。所以当10个用户同时发起请求时，连接池会创建满10个连接来并行处理这些请求。

当请求完成、连接被释放后，这些连接不会被销毁——连接池的核心价值就是复用连接，减少创建/销毁连接的开销。释放后的连接会变成空闲连接，保留在池中等待下一次请求复用，所以连接数不会归零，会维持在10个左右（除非你设置了idleTimeout，空闲超时后才会自动销毁多余的连接）。

2. 若连接池上限为50，因数据库查询仅耗时数毫秒，该连接池是否可支持数千用户？ #

完全可以！这里的关键是连接的复用效率：
每个查询只耗时几毫秒，意味着一个连接每秒可以处理几百次请求（比如1000ms / 5ms = 200次/秒）。50个连接的话，理论上每秒能处理50×200=10000次请求，完全能覆盖数千用户的操作——毕竟用户的操作不是持续不间断的，存在大量空闲间隔，连接可以快速周转服务更多请求。

3. 在上述场景下，AWS RDS监控中的“DB connections (count)”指标会维持1个连接还是峰值达到10个？ #

这个指标统计的是RDS当前实际建立的数据库连接数。当10个用户同时操作时，连接池会向RDS建立10个活跃连接，所以这个指标的峰值会达到10个。

当请求完成后，连接回到连接池变成空闲状态，但这些连接依然和RDS保持着TCP连接，所以指标会维持在10个（直到空闲连接超时被销毁，或者连接池主动关闭空闲连接）。

4. 若连接池上限设为8，上述场景中剩余2个请求会进入排队吗？ #

是的。当连接池的8个连接都被占用时，后续的请求会进入等待队列，直到有连接被释放回池中，才会被取出使用。

默认情况下，mysql连接池的queueLimit参数是0（无限制排队），这些排队的请求会一直等待直到拿到连接；如果你显式设置了queueLimit，超过队列长度的请求会直接抛出“No connections available”之类的错误。

5. 限制连接池上限的因素是否仅为数据库的处理能力？例如当DB的内存/CPU性能出现问题时，是否需调小连接池上限，反之则调大？ #

不止数据库处理能力，还有几个关键因素需要考虑：

• RDS实例的最大连接数限制：每个RDS实例都有max_connections参数（比如t2.micro默认是66），你的连接池上限绝对不能超过这个值，否则会触发“Too many connections”错误。
• 连接的内存开销：每个数据库连接都会占用RDS的内存（通常每个连接占几MB），如果连接数过多，哪怕CPU没跑满，也会耗尽RDS的内存，导致性能骤降甚至崩溃。
• Lambda的并发限制：Lambda本身有并发执行上限（默认1000），如果Lambda并发很高但连接池太小，会导致大量请求排队等待连接，拖慢响应速度；但也不能盲目调大连接池，否则会超出RDS的承受能力。
• 业务请求模式：如果你的业务有大量长耗时查询（比如几秒级），连接周转慢，连接池上限需要适当调高；如果都是像你这样的毫秒级短查询，不用太高的上限就能支撑大量请求。

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