2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
我们的应用程序接口一切正常。数据库也一切正常。那么为什么查询需要 16 秒？
这一切始于一个支持工单。一个面向客户的应用程序接口通常会在 200 毫秒内响应，但偶尔会飙升至 16 秒。并非每个请求都如此——但频率足以让人感到不安。
我们运行的是一个相当标准的无服务器技术栈：亚马逊网络服务 Lambda（Node.js）、在 Aurora MySQL 前面的关系型数据库服务代理，以及处理所有数据库交互的 Prisma 对象关系映射工具。大约有 27 个微服务、13 个数据库模式，以及通过共享依赖注入容器管理的大约 14 个 Prisma 客户端实例。它在数月间一直运行良好。
那么，是什么发生了变化呢？老实说，什么也没变。而这正是令人困惑的地方。
日志中的幽灵
我们做的第一件事是检查应用程序日志。一个简单的查询——比如“按身份标识获取客户信息”——从 Lambda 的角度来看，耗时被报告为 16 秒。我们从日志中提取了相同的查询，并针对数据库手动运行它。
3.2 毫秒
没错。三毫秒。
因此，数据库很快。查询也很快。但我们的应用程序却经历了 16 秒的……某种延迟。时间消耗在 Lambda 和数据库之间的某个地方，而我们不知道具体在哪里。
顺藤摸瓜找到关系型数据库服务代理
由于查询本身并不慢，我们开始检查连接层。我们使用关系型数据库服务代理来管理 Lambda 集群的连接池——这是避免数百个短生命周期连接压垮 Aurora 的标准做法。
我们打开云监控服务，查看了一个我们此前确实未曾过多关注的指标：
DatabaseConnectionsCurrentlySessionPinned（当前会话绑定的数据库连接数）
问题就出在这里。在业务高峰期，我们观察到有 400 到 870 个被绑定的连接。
对于不熟悉的人来说：关系型数据库服务代理的全部目的是多路复用数据库连接。多个 Lambda 调用应该共享一小部分后端连接。但是，当一个连接被“绑定”时，代理会将该后端连接专门分配给一个客户端会话。它不能被共享。也不能被重用。它就那样闲置着，如同被劫持一般。
有了 870 个被绑定的连接，我们的代理基本上失去了代理功能。Lambda 调用正在排队，等待被绑定的连接释放，而这段等待时间在应用程序端表现为查询延迟。
但是，为什么连接会被绑定呢？
关系型数据库服务代理日志揭示真相
我们使用云监控日志洞察深入研究了关系型数据库服务代理日志组（/rds/proxy）：
fields @timestamp, @message
| filter @message like /pinned/ or @message like /Pinning/
| sort @timestamp desc
| limit 200
最主要的绑定原因，每分钟出现数百次：
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
