在解决GraphQL中的数据库分页结果时，遇到一个真正的游标很难解决。无论我使用哪种数据库（SQL（例如mysql）或NoSQL文档（例如mongodb）），我都无法获得游标或类似游标的对象。
可能我错过了一些基本概念，但是在寻找答案之后，我开始严重怀疑官方GraphQL分页文档是否存在
https://graphql.org/learn/pagination/
完全基于任何真实的现场体验。
这是我的问题：我怎么能从像这样的SQL查询中远程获得类似于游标的任何东西？
SELECT authors.id, authors.last_name, authors.created_at FROM authors
ORDER BY authors.last_name, author.created_at
LIMIT 10
OFFSET 20
我知道，不应使用基于偏移的分页，而是将基于光标的导航视为一种补救措施。而且，我绝对想从胶印病中治愈我的应用。但是要做到这一点，我需要能够从某处检索光标。
我也了解（忘记了阅读的地方）也不应该将主键用于分页。
所以，我被困在这里。
答案 0 :(得分：6)
我认为您因提出一个好的问题而被否决。 first / last / before / after概念很难在SQL中实现。
我一直在为同样的问题而烦恼。分页文档没有介绍应用自定义ORDER语句时如何定义游标。
我也没有真正在网上找到全面的解决方案。我找到了一些人们正在解决该问题的帖子，但是答案仅部分正确或部分完整（只是base64编码ID字段以使游标看起来像是首选答案，但这几乎没有说明查询的内容）必须计算游标）。同样，涉及 row_number 的任何解决方案都很难看，不适用于不同的SQL方言。因此，让我们尝试不同的方式。
快速免责声明，这将是一篇相当全面的文章，但是如果您的后端使用了不错的查询构建器，则可以从技术上编程一种方法，该方法可用于实现Relay所需的第一个/最后/之前/之后的分页GraphQL到 ANY 预先存在的查询上。唯一的要求是，所有要排序的表都具有一列，该列唯一地代表记录的默认顺序（通常，如果主键是整数并且使用自动生成的ID，即使从技术上讲，您也可以使用该列）通过其主键对表进行排序并不总是会得到与无序返回表相同的结果）
暂时忽略base64，只需假设ID是代表表默认顺序的有效游标字段即可。
您在网上找到的使用光标的答案通常是这样。
SELECT * FROM TABLE T
WHERE T.id > $cursorId;
好吧，这非常有用，因为它不将任何其他种类应用于查询，所以可以将所有条目作为LONG形式获取。一旦您在示例中使用了自定义排序，该建议就会失效。
但是，其中的核心逻辑可以重新应用于具有种类的查询，但是解决方案需要扩展。让我们尝试提出完整的算法。
c之后的前n个 （光标之后的前n个节点）的算法
节点或边与SQL术语中的行相同。 （如果1行代表一个实体，例如1位作者）
当光标是该行之后，我们将开始返回同级行，无论是向前还是向后。
给出 C 是光标
A 是与 C 相比较的任何其他行。
T 是其中 A 和 C 均为行的表。
和 vwxyz 是表 T 上的5列，自然地， A 和 C 都有这些列。 / p>
该算法必须根据给定n的游标对象以及这5列提供的顺序来决定是否将A包含在返回查询中。
让我们从一个订单开始。
给定1个顺序（v） ：（如果我们假设我们的表默认情况下按其主键排序，则应该至少有一个顺序） 要显示前n条记录，我们需要应用 n个限制，这很简单。困难的部分是在c 之后。
对于仅按1个字段排序的表，该字段将归结为：
SELECT A FROM T
WHERE A.v > C.v
ORDER BY T.v ASC
LIMIT n
这应该显示v大于C的所有行，并删除v小于C的所有行，这意味着C之前将不剩任何行。如果我们假定主键正确地表示自然订单，我们 可以删除ORDER BY语句。然后，该查询的可读性会更高：
SELECT A FROM T
WHERE A.id > $cursorIdGivenByClient
LIMIT n
在这里，我们找到了最简单的解决方案，用于为“未排序”表提供游标。这与处理游标的普遍接受的答案是相同的解决方案，但是不完整。
现在让我们看一下按两列（ v 和 w ）排序的查询：
SELECT A FROM T
WHERE A.v > C.v
OR (A.v = C.v AND A.w > C.w)
ORDER BY T.v ASC, T.w ASC
LIMIT n
我们从相同的WHERE A.v > C.v开始，将值v（A.v）小于第一类（C.v）的C值的任何行从输出结果中删除。但是，如果第一阶v的列对于A和C具有相同的值，A.v = C.v我们需要查看第二阶列以查看是否仍允许在查询结果中显示A。如果A.w > C.w
让我们继续进行3种查询：
SELECT A FROM T
WHERE A.v > C.v
OR (A.v = C.v AND A.w > C.w)
OR (A.v = C.v AND A.w = C.w AND A.x > C.x)
ORDER BY T.v ASC, T.w ASC, T.x ASC
LIMIT n
这与2种排序的逻辑相同，但要多一些。如果第一列相同，我们需要查看第二列以了解谁是最大的列。如果第二列也相同，则需要查看第三列。重要的是要认识到，主键始终是ORDER BY语句中的最后一个排序列，也是要与之进行比较的最后一个条件。在这种情况下，A.x> C.x（或A.id> $ cursorId）
无论如何，应该开始出现一种模式。要对4列进行排序，查询将如下所示：
SELECT A FROM T
WHERE A.v > C.v
OR (A.v = C.v AND A.w > C.w)
OR (A.v = C.v AND A.w = C.w AND A.x > C.x)
OR (A.v = C.v AND A.w = C.w AND A.x = C.x AND A.y > C.y)
ORDER BY T.v ASC, T.w ASC, T.x ASC, T.y ASC
LIMIT n
最后是对5列进行排序。
SELECT A FROM T
WHERE A.v > C.v
OR (A.v = C.v AND A.w > C.w)
OR (A.v = C.v AND A.w = C.w AND A.x > C.x)
OR (A.v = C.v AND A.w = C.w AND A.x = C.x AND A.y > C.y)
OR (A.v = C.v AND A.w = C.w AND A.x = C.x AND A.y = C.y AND A.z > C.z)
ORDER BY T.v ASC, T.w ASC, T.x ASC, T.y ASC, T.z ASC
LIMIT n
这是一个令人恐惧的比较。对于每个添加的订单，计算 c之后的第n个所需的比较次数将根据在每一行执行的Triangular Number而增加。幸运的是，我们可以应用一些布尔代数来压缩和优化此查询。
SELECT A FROM T
WHERE (A.v > C.v OR
(A.v = C.v AND
(A.w > C.w OR
(A.w = C.w AND
(A.x > C.x OR
(A.x = C.x AND
(A.y > C.y OR
(A.y = C.y AND
(A.z > C.z)))))))))
ORDER BY T.v ASC, T.w ASC, T.x ASC, T.y ASC, T.z ASC
LIMIT n
即使浓缩后，图案也很清晰。每条条件线在“与”或之间改变，而每条条件线在>和=之间改变，最后每2条条件线我们比较下一个顺序列。
这种比较也令人惊讶。在第一次A.v> C.v检查之后，平均所有行中的一半将合格，并在此处停止。在通过的另一半中，大多数将在第二次A.v = C.v检查失败并在那里停止。因此，尽管它可能会产生大量查询，但我不会太担心性能。
但是让我们具体化一下，并用它来为您提供有关如何将光标用于所涉及示例的答案：
SELECT authors.id, authors.last_name, authors.created_at FROM authors
ORDER BY authors.last_name, author.created_at
您的基本查询是否已排序，但尚未分页。
您的服务器收到一个请求，要求显示“有光标的作者之后的前20位作者” 解码游标后，我们发现它代表ID为15的作者。
首先，我们可以运行一个小的前驱查询以获取我们将需要的必要信息：
$authorLastName, $authorCreatedAt =
SELECT authors.last_name, authors.created_at from author where id = 15;
然后我们应用算法并替换字段：
SELECT a.id, a.last_name, a.created_at FROM authors a
WHERE (a.last_name > $authorLastName OR
(a.last_name = $authorLastName AND
(a.created_at > $authorCreatedAt OR
(a.created_at = $authorCreatedAt AND
(a.id > 15)))))
ORDER BY a.last_name, a.created_at, a.id
LIMIT 20;
此查询将根据查询的类型正确返回ID为15的作者之后的前20位作者。
如果您不喜欢使用变量或二级查询，也可以使用子查询：
SELECT a.id, a.last_name, a.created_at FROM authors a
WHERE (a.last_name > (select last_name from authors where id 15) OR
(a.last_name = (select last_name from authors where id 15) AND
(a.created_at > (select created_at from authors where id 15) OR
(a.created_at = (select created_at from authors where id 15) AND
(a.id > 15)))))
ORDER BY a.last_name, a.created_at, a.id
LIMIT 20;
同样，它看起来还不错，子查询没有关联，结果将被缓存在行循环中，因此对性能不会造成特别的影响。但是查询确实变得混乱，尤其是当您开始使用JOINS时，该查询也需要在子查询中应用。
您不需要在a.id上显式调用ORDER，但是我这样做是为了与算法保持一致。如果您使用DESC而不是ASC，这确实变得非常重要。
那么，如果使用DESC列而不是ASC会发生什么？算法会中断吗？好吧，如果您套用一些额外的小规则，那就不行了。对于使用DESC而不是ASC的任何列，都可以将'>'符号替换为'<'，并且该算法现在可以在两个方向上进行排序。
JOINS对此算法没有影响（感谢上帝），除了来自联接表的20行不一定代表20个实体（在这种情况下为20个作者）这一事实之外，但这是一个与整体无关的问题首先/之后，您还将使用OFFSET。
处理已经具有预先存在的WHERE条件的查询也不是特别困难。您只需获取所有预先存在的条件，将它们包装在方括号中，然后将它们与AND语句结合起来即可使用算法生成的条件。
在这里，我们已经实现了一种算法，该算法可以处理任何输入查询并使用first / after正确分页。 （如果我错过了一些极端情况，请告诉我）
您可以在这里停下来，但是...不幸的是
您仍然需要处理前n ，后n ，在c 之前，在c 之后，
您可以使用我刚刚提供的给定AFTER算法中途学习。但是对于另一半，您将需要使用之前算法。它与AFTER算法非常相似：
SELECT A FROM T
WHERE (A.v < C.v OR
(A.v = C.v AND
(A.w < C.w OR
(A.w = C.w AND
(A.x < C.x OR
(A.x = C.x AND
(A.y < C.y OR
(A.y = C.y AND
(A.z < C.z)))))))))
ORDER BY T.v ASC, T.w ASC, T.x ASC, T.y ASC, T.z ASC
LIMIT n
要获得BEFORE算法，可以采用AFTER算法，然后将所有'<'运算符切换为'>'运算符，反之亦然。 （因此，本质上，之前和之后的算法是相同的，前/后+ ASC / DESC确定操作员必须指向哪个方向。）
对于“前n个”，除了对查询应用“ LIMIT n”之外，您无需执行任何操作。
对于“最后一个n”，您需要应用“ LIMIT n”并反转所有给定的ORDERS，将ASC与DESC切换，将DESC与ASC切换。 'last n'有一个警告，尽管它将正确地返回最后n条记录，但它会以相反的顺序进行，因此您需要再次手动反向返回的集，无论是在数据库中还是在代码内部。
有了这些规则，您就可以使用唯一的可排序列（通常是主键）作为游标，将来自中继GraphQL规范的任何分页请求成功集成到任何SQL查询中，该游标表示表默认排序的真实来源。
这相当令人生畏，但我设法使用这些算法为Doctrine DQL构建器编写了一个插件，以使用MySQL数据库实现分页方法中的first / last / before / after方法。因此，这绝对是可行的。