在传统的基于服务器的 Web 应用程序中，应用程序可以在启动时池化多个数据库连接，并在应用程序的整个生命周期内使用这些连接来处理客户端请求。性能优势，因为创建/销毁数据库连接的开销仅在启动/终止时支付一次。
在无服务器模型(如 google cloud function/AWS-lambda 等(中，应用程序启动，请求被处理，应用程序被关闭。因此，应用程序无法池化连接，以便对多个请求使用。
在无服务器模型中，提高数据库连接性能的适当设计模式(如果有(是什么？最后，如果不存在解决方案，来自无服务器体系结构的数据库请求是否会降低性能？预计会出现什么样的放缓？
Amazon RDS有一项专门为解决此问题而构建的新服务，即 Amazon RDS Proxy。
当您查看无服务器解决方案时，例如 Cloud Run、Cloud Function 甚至 Lambda(但我不会谈论它，因为我真的不知道 AWS(，实例是根据流量创建的。
我同意你的看法，你不管理何时创建和杀死实例，但不是在每个请求上创建一个实例。实际上，这些实例是重用的。顺便说一下，创建实例时，您只需"支付"冷启动的 1 倍，包括数据库池创建。同一实例上的后续请求(称为热启动(可以重用池，直到实例被底层平台终止。顺便说一下，将此池存储在全局变量中，以便在同一实例上逐个请求重用它。
要优化池大小，请仔细查看平台行为。例如，Cloud Function(我认为Lambda，没有承诺(可以同时处理每个实例的1个请求。顺便说一下，当您创建池时，创建一个只有 1 个数据库连接的池，更多是无用的，因为永远不会使用更多的池连接！例如，在 Java 中，我知道默认池每个默认创建 50 个连接，请注意这一点！
为什么？？，因为您的数据库有可能的连接数限制。这就是为什么，您还可以限制 Cloud Function 上并行的最大实例数，以避免任何数据库连接问题(--max-instances参数(。如果您的数据库接受 400 个连接，则同时使用的云函数不得超过 400 个！
现在，看看Cloud Run(和AppEngine，相同的行为(。借助 Cloud Run，您可以在同一时间在同一实例上处理多达 80 个并发请求。这一次，将池大小和/或 Cloud Run 上的concurrency参数设置为相等。例如，将并发设置为 40，将池大小设置为 40 个连接。
与云函数的建议相同，数据库接受 400 个连接，在最后一个示例中，这次将 Cloud Run 上的--max-instances参数设置为 10。
此限制对于通过池保存数据库连接非常重要，但如果对访问 API 或其他内容具有相同的限制，也可以使用它。