官方文档地址：https://uniapp.dcloud.net.cn/uniCloud/db-performance.html#skip
官方建议，当数量量大时，可以根据创建时间来排序，然后每次查询小于上一次查询最后一个数据的创建时间，
但是当有批量创建的业务时，就会出现多个创建时间相同的数据，比如每次查询20条，但在第18到23条数据的创建时间都一样的情况下，当第二次查询的时候，就查不到第21-23条的数据，从第24条数据开始查
请问这种情况应该怎么优化不会导致查询超时呢
efficient_work
- 发布：2022-08-03 19:22
- 更新：2022-08-10 09:49
- 阅读：452
4 个回复
efficient_work (作者)
来个大佬吧:(
efficient_work (作者)
一个折中的方案，第二次以及以后的查询，不要created_time<上一次查询最后一个数据的创建时间,而要使用
<=，但是这样会导致重复了第18,19,20条的数据，需要去重一下，efficient_work (作者)
这里还有一个bug，因为有重复数据，如果还是遍历原来计算的页数，可能出现后面的数据查不到
2022-08-04 16:24
DCloud_uniCloud_WYQ
回复 efficient_work: 再加一个唯一的标志比如_id作为排序字段
2022-08-04 16:26
efficient_work (作者)
回复 DCloud_uniCloud_WYQ: 加一个_id作为排序的字段也没用吧，比如我有60条数据，每次查询20条，18条数据到13条数据的创建时间都一样，结果第二次查询的条件是小于这个创建时间，就导致第21到23条数据都跳过了，直接查24-33条数据了
2022-08-04 18:11
DCloud_uniCloud_WYQ
回复 efficient_work: 时间相同时会以_id再进行排序，你再理解理解
2022-08-05 11:59
efficient_work (作者)
回复 DCloud_uniCloud_WYQ: 确实有用，但是还是会有数据漏掉，见下面回复截图。我测试是查询了7月1日到7月31日的数据，总数是826条，然后我分3次查，每次400条，最后一次只查了25条，就是漏了一条，如果我不加_id的排序，只查到700多条，那个截图我就不放了，证明加_id是有用的，但是为什么还是漏了一条数据呢
2022-08-06 10:46
efficient_work (作者)
回复 DCloud_uniCloud_WYQ: 这个地方还是不行的，我把每次查询条数改为500，就是加了_id排序，都漏了几十条数据，无论怎么排序，总是有可能在两页之间的时间是一样的，因为你的查询条件是只有work_time这一个
2022-08-08 10:31
efficient_work (作者)
分别是查询的总数，以及每次查询小于上一次的工作时间，最后一次数据少了一条
DCloud_uniCloud_WYQ
_id也应该是查询条件
2022-08-08 11:11
efficient_work (作者)
回复 DCloud_uniCloud_WYQ: 这个_id怎么放到查询条件呢，也是取上一次查询的最后一条数据的_id吗，这样？_id<"62d11b89f79299000193fa69"，但是查的数据条数还是不对
2022-08-09 09:53
efficient_work (作者)
回复 DCloud_uniCloud_WYQ: 兄弟，看下下面截图，加了_id还是不行
2022-08-10 09:50
efficient_work (作者)
回复 DCloud_uniCloud_WYQ: 兄弟，能回答一下嘛，加了_id这样写查出来的数据不对
2022-08-12 12:01
efficient_work (作者)
总数826条，一次查询500条，第二次只查出165条
DCloud_uniCloud_WYQ
你把work_time大于等于这个条件去掉，另外这个条件写起来比较复杂。你需要获取的是work_time< last_work_time || work_time == last_work_time && _id < last_work_id
2022-08-15 11:51
efficient_work (作者)
回复 DCloud_uniCloud_WYQ: 感谢感谢，我一直纠结于的写法的问题，原来就是逻辑判断一下就可以
2022-08-15 12:19