疑难解答
在使用 Prisma Accelerate 时，您可能会在开发和运营过程中遇到错误，这些错误通常用特定错误代码突出显示。了解这些错误的含义、发生原因以及如何解决它们对于确保应用程序的顺利运行至关重要。本指南旨在提供见解和步骤，帮助您解决使用 Prisma Accelerate 时遇到的特定错误代码。
P6009 (ResponseSizeLimitExceeded)
当数据库查询的响应大小超过 配置的查询响应大小限制 时，会触发此错误。我们实施了此限制来保护您的应用程序性能，因为检索超过 5MB 的数据会导致多个网络层导致应用程序速度明显变慢。通常，在执行 ETL（提取、转换、加载）操作时，传输超过 5MB 的数据很常见。但是，对于其他场景（例如事务性查询、用于用户界面的实时数据获取、批量数据更新或汇总 ETL 上下文之外的分析的大型数据集）来说，通常应避免这种情况。这些用例虽然必不可少，但通常可以优化以在 配置的查询响应大小限制 内运行，从而确保更流畅的性能和更好的用户体验。
P6009 的可能原因
传输响应中的图像/文件
如果您的表中存储的图像或文件正在被获取，从而导致响应大小很大，则可能会出现此错误。通常不建议将资产直接存储在数据库中，因为这会严重影响数据库的性能和可扩展性。除了性能之外，它还会使数据库备份变慢，并显着增加存储例行备份的成本。
建议的解决方案：将 查询响应大小限制 配置为更大。如果仍然超过限制，请考虑将图像或文件存储在像 Cloudflare R2、AWS S3 或 Cloudinary 等 BLOB 存储中。这些服务允许您以最佳方式存储资产并返回一个 URL 以供访问。不要将资产直接存储在数据库中，而是存储 URL，这将大大减少响应大小。
过度获取数据
在某些情况下，无意中获取了大量记录或字段，这会导致超过 配置的查询响应大小限制。当查询中的 where 子句不正确或完全缺失时，就会发生这种情况。
建议的解决方案：将 查询响应大小限制 配置为更大。如果仍然超过限制，请仔细检查 where 子句是否按预期过滤数据。为了防止获取太多记录，请考虑使用 分页。此外，使用 select 子句仅返回必要的字段，从而减小响应大小。
获取大量数据
在许多数据处理工作流中，尤其是那些涉及 ETL（提取-转换-加载）流程或计划的 CRON 作业的工作流中，需要从数据源（如数据库、API 或文件系统）提取大量数据以进行分析、报告或进一步处理。如果您正在运行从数据源（如数据库、API 或文件系统）提取大量数据以进行分析、报告或进一步处理的 ETL/CRON 工作负载，那么您可能会遇到此限制。
建议的解决方案：将 查询响应大小限制 配置为更大。如果仍然超过限制，请考虑将查询拆分为批次。这种方法确保每个批次仅获取一部分数据，从而防止您在单个操作中超过大小限制。
P6004 (QueryTimeout)
当数据库查询在 配置的查询超时限制 内无法返回响应时，会发生此错误。查询超时限制包括等待连接池中连接的持续时间、到数据库的网络延迟以及查询本身的执行时间。我们实施此限制是为了防止意外的长时间运行的查询，这些查询会导致系统资源过载。
Accelerate 的跨区域网络时间不包括在 配置的查询超时限制 限制内。
P6004 的可能原因
此错误可能是由多种原因引起的。一些突出的原因是
高流量和连接不足
如果应用程序接收非常高的流量，并且没有足够的连接可用到数据库，那么查询将需要等待连接可用。这种情况会导致查询等待的时间超过 配置的查询超时限制 以获得连接，如果它们在此持续时间内未得到服务，最终会导致超时错误。
建议的解决方案：在平台环境中设置 Accelerate 时，查看并可能增加连接字符串参数中指定的 connection_limit（参考）。此限制应与数据库的最大连接数保持一致。
默认情况下，连接限制设置为 10，除非您的数据库连接字符串中指定了不同的 connection_limit。
长时间运行的查询
查询的响应速度可能很慢，即使连接可用，也会达到 配置的查询超时限制。如果在单个查询中获取了大量数据，或者表中缺少适当的索引，就会发生这种情况。
建议的解决方案：将 查询超时限制 配置为更大。如果仍然超过限制，请识别缓慢运行的查询，并仅获取必要的数据。使用 select 子句检索特定字段，并避免获取不必要的数据。此外，请考虑添加适当的索引以提高查询效率。您还可以将长时间运行的查询隔离到单独的环境中，以防止它们影响事务性查询。
数据库资源争用
一个常见但具有挑战性的问题是，当在同一数据库上运行的其他服务执行繁重的分析或数据处理任务时，会大量消耗数据库资源。这些操作会独占数据库连接和处理能力，从而导致即使简单的查询也无法及时执行。这种“繁忙”或“嘈杂”的数据库环境会导致通常快速运行的查询变慢甚至超时，尤其是在其他服务的高活动期间。
用户通常依靠 CPU 和内存使用率指标来衡量数据库负载，这可能会产生误导。虽然这些指标很重要，但它们可能无法完全代表数据库的操作状态。读取次数、写入次数和等待时间的直接指标可以更清晰地了解数据库的性能，应密切监控。这些指标的明显下降，尤其是在没有对查询或数据模型进行更改的情况下，表明外部压力正在影响数据库性能。
建议的解决方案：如果通常快速的查询间歇性地变慢或超时，而没有对其进行任何修改，那么很可能是竞争查询对同一数据库表施加了压力。要诊断此问题，请采用监控工具或利用数据库的固有功能来观察读取次数、写入次数和等待时间。此类监控将揭示与观察到的性能下降一致的活动模式或峰值。
此外，定期审查和改进基本查询并验证表是否正确索引至关重要。这种积极主动的方法将最大限度地减少这些查询因竞争工作负载而导致的减速。
有关 P6009 和 P6004 错误的注意事项
对于原生支持 Prisma ORM 的运行时，您可以考虑创建两个 PrismaClient 实例。一个使用 Accelerate 连接字符串（以 prisma:// 为前缀），另一个使用直接数据库连接字符串（以 postgres://、mysql:// 等为前缀）。这种方法背后的主要思想是绕过 Accelerate，针对某些特定查询执行操作。
但是，请注意，可用的连接将分配到您的两个 PrismaClient 实例之间。了解管理多个实例的影响至关重要，尤其是在直接数据库连接方面。使用带有直接数据库连接字符串的 PrismaClient 实例意味着该连接将直接与您的数据库交互。
这种方法需要慎重考虑，因为直接连接和由 Accelerate 管理的连接共享相同的底层数据库连接池。这会导致资源竞争，可能影响数据库服务的性能和可用性。
此外，直接连接可能会对数据库的性能和可用性产生重大影响。消耗大量资源的操作可能会降低其他依赖于同一数据库的用户或进程的服务质量。
如果您的应用程序运行时环境原生支持 Prisma ORM，并且您正在考虑使用此策略来规避 P6009 和 P6004 错误，则可以创建两个 PrismaClient 实例。
- 一个实例使用 Accelerate 连接字符串（以
prisma://为前缀）进行一般操作。 - 另一个实例使用直接数据库连接字符串（例如，以
postgres://、mysql://等为前缀）进行特定操作，预计这些操作将超出 配置的查询限制超时时间 或导致响应大于 配置的查询响应大小限制。
export const prisma = new PrismaClient({
datasourceUrl: process.env.DIRECT_DB_CONNECTION,
})
export const prismaAccelerate = new PrismaClient({
datasourceUrl: process.env.ACCELERATE_CONNECTION,
}).$extends(withAccelerate())
这种设置使您可以策略性地将某些操作通过直接连接执行，从而减轻遇到上述错误的风险。但是，应在全面了解潜在后果的基础上做出此决定，并评估您的数据库基础设施是否能够在不影响整体性能和可用性的情况下支持此额外的负载。
P6008 (ConnectionError|EngineStartError)
此错误表明 Prisma Accelerate 无法建立与您的数据库的连接，这可能是由于多种原因造成的。
导致 P6008 的可能原因
数据库无法公开访问
如果您的数据库位于 VPC 中，或者访问权限仅限于特定的 IP 地址，则如果未为 Accelerate 启用静态 IP，或如果您的数据库防火墙不允许来自静态 IP 的访问，则可能会遇到此错误。
建议的解决方案： 为 Accelerate 启用静态 IP，并配置您的数据库防火墙，以允许来自提供的静态 IP 地址的访问。
无法访问数据库主机/端口
如果数据库的服务器地址（主机名）和端口不正确或无法访问，则可能会遇到此错误。
建议的解决方案： 验证创建 Prisma Accelerate 项目时提供的数据库连接字符串的主机名/端口。此外，尝试使用数据库 GUI 工具（例如，Prisma Studio、TablePlus 或 DataGrip）进行进一步调查。
用户名/密码/数据库名称不正确
当向 Prisma Accelerate 提供错误的凭据时，可能会发生此错误，从而阻止其建立与您的数据库的连接。
建议的解决方案： 验证您提供给 Prisma Accelerate 的连接字符串中数据库的用户名、密码和名称是否正确。确保这些凭据与您的数据库要求的凭据匹配。使用直接数据库 GUI 工具测试连接也可以帮助您确认提供的凭据是否正确。