@auh #47 万分感激，我还一直在分页这里面琢磨。。。 实际上这里就是分批次拿数据，都不应该叫做分页了！

@auh 谢谢

@fkname #48 感谢，是个很好的办法！

@YouLMAO #25 并且，我这是一篇求助帖，而不是教程帖。

@lldld #29 暂时先记录所有吧，先出一个可以用的，然后再优化吧，这种不记录全部 id 的想法很棒！

@lldld 感谢，好的想法，学习到了！ ^^

@xyjincan #26 最开始就是打算的这个方案，可能我当时技术欠缺或者没想到如何优化性能，然后就不打算采取这个方案。现在有了性能优化方案以及整个查询逻辑的细节处理方法，就可以用啦。

问题不描述清楚，我光解释就要解释半天。

@hma 后续会考虑这方面的优化，谢谢！

@yzbythesea #28 关于用户一般就是存个 token，缓存一些用户数据，直接用 Redis 当用户表就没玩过了

@zieglar #24 这样确实也可以，谢谢你的思路。
如果把数据全部维护到 Redis，个人不太喜欢这样的处理方式。
处理方式挺不错的，如果后续有其他需求可以用到这个思路！

@yzbythesea #28 我没有这样处理过

@YouLMAO 我说了这是一个类似随机的方案，因为直接采取随机的话，会出现重复的数据，不满足需求。如果想实现随机+不重复 你可以在取数据的时候进行随机获取并踢除已看视频，如果数据不足一页就一次查询多页，查询多页需要注意一个问题，看第 23 楼

@CandyMuj 还有一点，记录历史记录的时候是每次查询都记录视频 id，但是查询由于是分页的，在查询的时候需要加一个限制 historyId <= 第一页查询时的最大历史记录 id,不然就会出现下面的问题
有数据 id：1 2 3 4 5 6 7 8 9 10
首次查询不剔除数据
第一页：limit 0,2 => 1 2
记录看过的：1 2
第二页查询：
此时就剔除 1234：3 4 5 6 7 8 9 10
查询：limit 2,2 => 5 6

就会导致有些数据是被直接跳过了

@CandyMuj 还有一点，记录历史记录的时候是每次查询都记录视频 id，但是查询由于是分页的，在查询的时候需要加一个限制 historyId <= 第一页查询时的最大历史记录 id,不然就会出现下面的问题
有数据 id：1 2 3 4 5 6 7 8 9 10
首次查询不剔除数据
第一页：limit 0,2 => 1 2 3 4
记录看过的：1 2 3 4
第二页查询：
此时就剔除 1234：5 6 7 8 9 10
查询：limit 2,2 => 7 8

就会导致有些数据是被直接跳过了

@yzbythesea 这种方式用 sql 查询的时候会用到 in(id1,id2,ids...)，这样的话不走索引的，或者有什么方法可以替代 in 么？而且这种操作一般都不会在 app 端做处理的。

@ylrshui 笨方法有时反而是最有效的方法，只要优化的好也能成为好的方法，哈哈哈！

@rrfeng 不过维护两个 lastid 这个想法挺不错的，是一个好的想法，谢谢。

不一一回复了，感谢所有回复的朋友，好的方案我会学习一下的，谢谢啦！ ^^

@rrfeng 谢谢，最开始就是这个，主要问题就在于这个数据的顺序会变，如果顺序不变就没问题 可以看看 14 楼的方案