首页 > 解决方案 > 尝试使用 1 到非常多的 JOIN 进行查询时,GraphQL 会破坏 SQL Server 吗?这样的 JOIN 会引起什么问题?

问题描述

我们的代码开发团队正在实施一个 GraphQL API 来替代我们网站访问 AWS RDS Web Edition SQL Server 2017 后端的当前方法。我注意到跨多个表的查询不使用数据库本机关系,而是单独加载每个表并传递每个表所需的行的过滤参数,这些参数源自先前的表键。

TSQL 查询示例:

Select c.Name
from a
inner join b on b.b_id = a.b_id
inner join c on c.c_id = b.c_id

类似的通过 GraphQL 生成。有点伪代码,因为它是 GraphQL 持有 SELECT 的结果:

Select a.b_id [into a table within GraphQL API. Let's call it *b_ids*] 
from a

Select b.c_id [again into a GraphQL table *c_ids*]
from b
where b.id IN([list of ids in *b_ids*])

Select c.Name
from c
WHERE c.id IN ([list of ids in *c_ids*])

我们在跟踪中看到的是:

Select a.b_id 
from a

Select b.c_id
from b
where b.id IN(1, 2, 3, 4 etc..)

Select c.Name
from c
WHERE c.id IN (1, 2, 3, 4 etc..)

我担心这种方法、可能会受到影响的性能以及可能在级联中的 1 到非常多的行上违反 SQL Server 查询 (64KB) 的阈值。我们有数十万行的联结表。

我会认为如果我的担忧是有效的,那么网上会有很多东西可以找到,但我什么也没找到。有没有人一起使用这些平台,可以提供一些指示、警告或保证,特别是在与需要快速响应的网站一起使用时。提示赞赏。

标签: sql-serverperformancegraphql

解决方案


我不知道 GraphQL,但是具有大IN列表的查询解析和编译成本可能很高,并且无法扩展到任意大小的数据。但是,对 TSQL 查询大小的限制是 ~65MB 而不是 64KB,在您达到该限制之前,性能应该成为一个问题。

作为更可扩展的替代方案,使用表值参数、JSON 数组或批量加载临时表来传递数据。


推荐阅读