本地使用Prisma连接远程Amazon RDS实例出现异常缓慢问题

核心根因 #

该性能差异完全来自高延迟公网链路下的数据库请求往返（RTT）叠加效应，和Prisma默认CRUD语句的生成逻辑直接相关：

• Prisma默认的create操作会自动生成隐式事务块，单次创建操作至少触发4次独立的客户端-数据库网络交互：
  • 发送BEGIN初始化事务
  • 发送INSERT语句执行写入
  • 发送SELECT语句拉取写入后的完整记录（包含数据库生成的默认值、触发器更新字段、关联表字段）
  • 发送COMMIT提交事务
• 公网直连AWS RDS的单轮RTT通常在200ms上下，4次往返的固定网络开销就达到800ms，加上语句本身的执行耗时，总延迟刚好落在测试得到的1000ms区间。
• 其余测试场景的性能表现完全符合RTT叠加逻辑：
  • 同VPC内部署Prisma连接RDS：单轮RTT仅1~3ms，4次往返总网络开销不到15ms，加上语句执行耗时总时长约100ms
  • 本地手写原生查询连接远程RDS：通常用单条INSERT ... RETURNING完成写入+结果返回，仅需1次网络往返，总耗时约100ms
  • 本地Prisma连接本地Postgres：单轮RTT低于1ms，哪怕10次以上往返总耗时也无法被感知，因此Prisma和原生查询无性能差异

观察到的「Prisma生成包含独立create、select语句的事务块冗余度更高」的线索是准确的，性能损耗并非来自语句本身的执行效率，而是高延迟链路下多轮网络往返的开销累加——这也是为什么该问题仅在「本地Prisma+远程RDS」的特定组合下出现，低延迟链路下多轮往返的开销完全可以忽略。

验证方法 #

可以通过开启Prisma查询日志，直接确认单次create操作触发的语句数量：
初始化Prisma客户端时开启query级日志：

const prisma = new PrismaClient({
  log: ['query'],
})

执行单次create操作后，控制台会按顺序输出BEGIN、INSERT、SELECT、COMMIT四条独立语句，每条语句对应一次完整的网络往返。

优化方案 #

按优化收益从高到低排序：

• 公网连接场景下，对性能敏感的写入操作直接使用$executeRaw编写带RETURNING子句的单条INSERT语句，仅需1次网络往返，性能和原生手写查询完全一致
• 批量写入场景统一使用createMany方法，该方法不会生成多语句隐式事务块，网络开销和原生批量插入基本持平
• 本地开发环境优先使用SSH隧道、AWS内网VPN等方式连接RDS，将单轮RTT降低到50ms以内，即使是默认的4次往返，总耗时也能降到200ms以内的可用水平
• 若必须使用默认create方法，可通过select参数显式指定需要返回的字段，降低SELECT语句本身的执行开销，但该方式无法减少网络往返次数，优化幅度有限

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