假设是一个论坛系统，首页显示最新发布的100个主题。另外，每个用户都可以设置自己希望屏蔽的用户，比如A设置了屏蔽B和C，那么A在查看首页的100个主题时就不包含B和C发布的内容。 如何尽量高效的实现？（可以采用缓存机制，但不用Redis）
认证高级PHP讲师
记住原则就好办：用户计算永远过剩，服务器计算永远不足。
那么办法就出来了：把文章列表按照100为单位切片，请求时对照用户自己的黑名单，发出剔掉了黑帖子之后不足100个的结果。 在客户端最好用JS动态加载。判断一下如果接收到的不足100个，向服务器请求下一个切片，直到最后填满为止。
这个方法也可以用于类似人人和新浪微博那样，无限长加载的带黑名单的列表。
注意，你一旦引入了黑名单，就只能用这种方式滚动加载了。打死也做不到像普通文章列表那样，每一页文章数固定，并能随便跳到后边的某个页数。
因为如果用时间堆（LIMIT分页）如LZ所说查询效率吃不消，每个用户都要花掉O(n^2)的时间；而用空间换时间，把每个用户每一页面的第一篇文章ID存储起来（这样就可以从这篇文章往下查），这也吃不消，因为这就要花掉O(n^2)的空间去存储。
玩过信息学竞赛的就很熟悉了：O(n^2)对于10000以上的规模等同于缴械投降。如果网站够小，也没问题，但线性的数据规模增长，如果带来平方级的计算压力，肯定是个头痛的大问题。
引入功能总是有代价的，说不好哪个功能就会撞到算法的极限，神仙也救不了。
你可以看一下。带黑名单的网站（人人/fb，各微博/twitter）是不是真的全都没有传统分页？
下面是我的思路，不知道能不能帮到你。
如果以 SQL 语句来筛选，那么对于每个用户这个结果都是不一样的，每个用户都要发生结果不一样的数据库查询，不好做缓存，这个方案不可取。
如果统一取出更多结果（比如 200 个）并缓存待用，显示时剔除用户屏蔽的记录显示给用户，这个对数据库的压力最小，似乎是一个不错的方案。
对于第二个方案会有什么特殊情况呢？
假如很不走运 200 个记录剔除后剩下不到 100 个甚至没了，这种情况是很少发生的（如果发生了，他是有多恨你的论坛。。。）
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
记住原则就好办：用户计算永远过剩，服务器计算永远不足。
那么办法就出来了：把文章列表按照100为单位切片，请求时对照用户自己的黑名单，发出剔掉了黑帖子之后不足100个的结果。
在客户端最好用JS动态加载。判断一下如果接收到的不足100个，向服务器请求下一个切片，直到最后填满为止。
这个方法也可以用于类似人人和新浪微博那样，无限长加载的带黑名单的列表。
注意，你一旦引入了黑名单，就只能用这种方式滚动加载了。打死也做不到像普通文章列表那样，每一页文章数固定，并能随便跳到后边的某个页数。
因为如果用时间堆（LIMIT分页）如LZ所说查询效率吃不消，每个用户都要花掉O(n^2)的时间；而用空间换时间，把每个用户每一页面的第一篇文章ID存储起来（这样就可以从这篇文章往下查），这也吃不消，因为这就要花掉O(n^2)的空间去存储。
玩过信息学竞赛的就很熟悉了：O(n^2)对于10000以上的规模等同于缴械投降。如果网站够小，也没问题，但线性的数据规模增长，如果带来平方级的计算压力，肯定是个头痛的大问题。
引入功能总是有代价的，说不好哪个功能就会撞到算法的极限，神仙也救不了。
你可以看一下。带黑名单的网站（人人/fb，各微博/twitter）是不是真的全都没有传统分页？
下面是我的思路，不知道能不能帮到你。
如果以 SQL 语句来筛选，那么对于每个用户这个结果都是不一样的，每个用户都要发生结果不一样的数据库查询，不好做缓存，这个方案不可取。
如果统一取出更多结果（比如 200 个）并缓存待用，显示时剔除用户屏蔽的记录显示给用户，这个对数据库的压力最小，似乎是一个不错的方案。
对于第二个方案会有什么特殊情况呢？
假如很不走运 200 个记录剔除后剩下不到 100 个甚至没了，这种情况是很少发生的（如果发生了，他是有多恨你的论坛。。。）