Prisma分页结合orderBy出现数据重复与缺失的原因及多条件排序适用场景

一、初始查询出现异常的原因 #

这个问题的核心是排序的不稳定性。

你初始的查询只按likesReceived._count降序排序，而大部分用户（4、5、6...14）的点赞数都是0——当多条记录的排序键值完全相同时，数据库（Prisma底层依赖数据库执行查询）没有默认的稳定排序规则。此时数据库会根据数据的物理存储位置、查询优化器的临时选择等不确定因素来排序，这就导致每次查询时，这些点赞数为0的用户的顺序可能不一样。

反映到分页上：

• 第一次查询page=0&size=5时，数据库可能把用户14排在了点赞数为0的用户的第一位，所以结果里出现了2、10、3、4、14；
• 第二次查询page=1&size=5时，排序顺序发生了变化，用户5被挤到了前5条点赞数为0的记录之外（被skip:5跳过），而用户14又出现在了后面的结果里；
• 最终就出现了用户14重复、用户5缺失的异常。

当你添加了id: "asc"作为二次排序后，所有点赞数相同的用户会按照唯一的ID升序排列，排序顺序彻底固定，分页的skip和take就能精准定位到正确的记录，自然就恢复正常了。

二、何时需要在orderBy中添加第二个排序参数？ #

只要你的主排序字段不是唯一值，就必须添加一个唯一的字段作为二次排序，才能保证分页功能的稳定性：

• 场景1：排序依据是统计类字段（比如点赞数、评论数、收藏数），多条记录很容易出现相同的统计值；
• 场景2：排序依据是非唯一的业务字段（比如用户名、注册日期、分类标签），可能存在多个记录共享同一个值；
• 本质上，只要存在多条记录的主排序键值相同的可能性，就需要补充唯一字段的二次排序，确保数据库每次返回的顺序完全一致，避免分页时出现重复、缺失数据的问题。

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