Amazon PostgreSQL RDS（db.t2.small）连接限制已改参数仍显示200，能否调整？

咱们来好好拆解下这个问题：这个200左右的连接限制并非AWS的不可修改硬限制，但它确实受实例硬件资源（核心是内存）的约束，具体细节如下：

• 为什么改了参数组还是显示200？
  db.t2.small实例只有2GB内存，PostgreSQL的实际最大连接数是由「参数组里设置的max_connections」和「实例内存能支撑的连接数」共同决定的。每个PostgreSQL连接都会占用不少内存（包括连接本身的基础开销、work_mem、temp_buffers等分配），默认配置下，2GB内存大概只能支撑200左右的并发连接。哪怕你在参数组里把max_connections设得更高，PostgreSQL也会自动向下调整到内存能承受的数值——这是系统的自我保护机制，避免内存耗尽导致实例崩溃。

• 那能不能把这个数值调得更高？
  可以，但得谨慎操作，同时要配套优化内存相关参数：

  1. 先确认你的自定义参数组已经应用到实例并完成重启——很多人改了参数组后忘了重启实例，导致设置根本没生效。
  2. 如果已经生效但连接数还是卡在200左右，你可以尝试调大max_connections，但必须同步降低其他内存消耗型参数，比如：
     • 减小work_mem（每个连接在排序、哈希操作时使用的内存）
     • 降低maintenance_work_mem（VACUUM、CREATE INDEX等维护操作的内存分配）
     • 合理调整shared_buffers（RDS里这个参数会根据实例类型预设，修改时建议不要超过总内存的25%）
  3. 更靠谱的方案是使用连接池工具（比如pgBouncer）：db.t2.small的内存本就有限，过多的物理连接会严重拖慢实例性能，连接池可以复用现有连接，在不增加物理连接数的前提下支撑更多业务请求，这比硬调max_connections要稳妥得多。

• 最后提个醒：
  如果你强行把max_connections设得远超内存承载能力，很可能会触发OOM（内存不足）、实例卡顿甚至自动重启，调整前一定要结合CloudWatch的内存使用率监控数据来判断。

内容的提问来源于stack exchange，提问作者Juraj Kostolanský