并发操作扩容时Prisma性能不一致问题排查求助

我在Node.js环境中使用Apollo搭建GraphQL后端，采用Prisma作为PostgreSQL的ORM层，部署于GCP Cloud Run，数据库使用GCP Cloud SQL托管的PostgreSQL实例。近期发现Prisma性能表现极不稳定，尤其在解析多数据库实体的复杂GraphQL解析器中，且问题随并发查询数量增加而恶化。已通过OpenTelemetry启用Prisma追踪功能排查，目前遇到三类主要问题：

问题1：等待连接时出现耗时的SELECT 1查询 #

已在PostgreSQL连接字符串中设置?connection_limit=40，理论上已为Prisma预留足够连接，但偶尔会出现prisma:engine:connection耗时达700ms至1秒的情况，而其他多数查询仅需50ms至100ms，原因不明。

问题2：单个查询耗时随并发查询数量增加而变长 #

同一GraphQL查询内的并发数据库查询数量提升时，相同的单个查询耗时会明显增加。低并发时多数查询耗时50ms至100ms，但在复杂解析器中相同查询耗时接近300ms。

我的PostgreSQL实例配置为2 vCPU、8GB内存，查看Cloud SQL控制台图表发现CPU使用率始终低于10%，活跃连接峰值约100（上限为400），Query Insights中也无异常查询性能数据，因此问题大概率出在Prisma或其配置上。

问题3：Prisma遥测追踪Span缺失 #

大量prisma:client:operationSpan仅包含prisma:client:serialize子Span，其余内容缺失。怀疑是未被 instrumentation 的DataLoader优化导致，或是Prisma追踪功能存在问题，原因不明。

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