哎，这种连接数异常上涨的问题真的很挠头，我之前也碰到过类似的场景，结合你的描述帮你梳理下可能的原因和排查方向，你可以一步步来验证：

先搞懂两个关键指标的区别 #

首先得明确你看到的两个状态变量的含义，避免理解偏差：

• Threads_connected：当前活跃的数据库连接数（正在执行操作或保持打开的连接），你的36是正常的活跃数
• Connections：数据库实例启动以来所有尝试建立的连接总数（包括成功和失败的，你的都是成功的，因为错误数都是0），它本身会随时间上涨，但你说重启后快速回升，说明连接建立的频率太高，这才是核心问题——正常来说RDS Proxy应该复用连接，不会频繁新建Aurora连接

核心排查方向 #

1. RDS Proxy的连接池配置可能出问题了 #

你用了RDS Proxy，它的核心作用就是做连接池复用，要是它没好好干活，就会不断给Aurora新建连接：

• 检查Proxy的目标连接池设置：比如「最大连接数」是不是设得过高，或者「最小空闲连接数」不合理？比如如果最小空闲设得太低，Proxy在流量低的时候会把连接都回收，流量上来又要重新建；如果空闲连接超时设得太短（比如小于Aurora的wait_timeout），Proxy的连接会被Aurora主动踢掉，只能反复新建
• 检查Proxy的连接泄漏检测：有没有开启连接泄漏检测功能？如果Lambda的连接没有正常归还，Proxy会不会一直挂着这个连接，直到超时才回收？

2. Lambda的连接复用代码可能没写对 #

你说把连接建在handler外面，但看你贴的代码，conn = get_db_connection()是在handler的try块里？这可能有坑：

• 确认get_db_connection()是不是真的复用了全局连接：比如有没有用全局变量保存连接实例，而不是每次调用都新建？举个正确的写法参考：

  # 全局变量，Lambda容器初始化时创建一次，容器复用时复用
  global_db_conn = None
  
  def get_db_connection():
      global global_db_conn
      # 检查连接是否存在且有效
      if global_db_conn is None or not global_db_conn.open:
          # 新建连接的逻辑
          global_db_conn = pymysql.connect(
              host=PROXY_ENDPOINT,
              user=DB_USER,
              password=DB_PASS,
              database=DB_NAME,
              autocommit=True  # 建议开启，避免事务挂起
          )
      return global_db_conn
  
  def lambda_handler(event, context):
      conn = None
      try:
          conn = get_db_connection()
          # 执行你的数据库操作
      except Exception as e:
          # 异常处理，比如回滚事务
          if conn:
              conn.rollback()
          raise e
      # 注意：不要在这里关闭连接！关闭了就没法复用了
  

• 如果你的代码每次执行完都调用conn.close()，那连接复用直接失效，每次请求都会新建连接，Connections肯定会疯涨
• 另外，PyMySQL的连接如果断了（比如被Proxy回收），有没有自动重连的逻辑？如果没有，旧的无效连接会被一直保留，导致每次调用都新建连接

3. Aurora的连接超时参数可能不匹配 #

Aurora的wait_timeout和interactive_timeout参数会影响空闲连接的生命周期：

• 如果这两个值设得太短（比如60秒），Proxy的空闲连接会被Aurora主动关闭，Proxy每次需要连接时只能重新建立，导致Connections累计上涨
• 如果设得太长（比如几小时），Proxy的闲置连接会一直挂在Aurora上，虽然Threads_connected不会涨，但Connections还是会随着新建连接慢慢增加
• 建议把这两个值设得比RDS Proxy的「空闲连接超时」稍长一点，比如Proxy超时设300秒，Aurora设360秒，避免Proxy的连接被提前踢掉

4. 检查Lambda的并发和容器销毁的影响 #

Lambda的容器会被AWS自动销毁（比如一段时间闲置后），这时候容器里的数据库连接应该被Proxy回收，但如果Proxy的回收不及时：

• 比如Proxy的连接检测超时设置太长，会导致这些已失效的连接在Aurora上挂一段时间，直到被Aurora的超时踢掉，期间如果有新的流量，Proxy又要新建连接，导致Connections上涨
• 另外，如果你的Lambda并发很高，Proxy可能会为每个并发的容器建立一个连接到Aurora，这时候如果并发突增，Connections会快速上涨，但流量降下来后Proxy应该会回收这些连接，如果没回收，那就是Proxy的配置有问题

下一步可以做的验证操作 #

1. 先查RDS Proxy的CloudWatch指标：重点看DatabaseConnections（Proxy到Aurora的连接数）、ClientConnections（Lambda到Proxy的连接数）、ConnectionLeaks，如果DatabaseConnections一直涨但ClientConnections没涨，说明Proxy在不断新建到Aurora的连接，复用率低
2. 临时调整Aurora的wait_timeout到300秒，同时把Proxy的空闲连接超时设为240秒，观察Connections的上涨速度会不会变慢
3. 检查你的get_db_connection()实现，确保它真的是复用全局连接，而不是每次新建
4. 开启PyMySQL的连接日志（如果方便的话），看看每次请求是不是真的复用了连接，还是每次都新建

如果还有疑问，可以再贴下你的get_db_connection()代码，或者Proxy的配置细节，我再帮你分析！