这是一个创建于 1858 天前的主题，其中的信息可能已经有所发展或是发生改变。
如果用 mysql NOT IN 排除的话基本不可行，这怎么做的呢？
 | 1 jjianwen68 2021 年 3 月 23 日 redis 缓存可能性更大吧 |
 | 2 ntdll 2021 年 3 月 23 日 这个更偏向业务设计问题，而不是技术问题。 未付费用户一天只能划限定的数量，假如是 100 个，业务低谷时期，查出来 100 个就完成了，今天随你怎么玩，都不查库了。 付费用户假设可以无限划，可以以安全名义限定超过 200 个以后，5 秒最多划一次，那么一天峰值也就不到 2 万个，也可以在业务低谷期预先查询出来。 --- 以上为假设，实际情况中，由于用户在地理位置上会移动，所以预先查询所有结果集是可能性不大的。 但是由于位置的限制，每次查询并不需要在所有用户中做排除条件，因此实际上 NOT IN 的性能开销很可能是可以接受的。偏僻的地区，可能周围 5 公里就几千个人，闹市区也许就几万人？ |
 | 4 ic2y 2021 年 3 月 23 日 布隆过滤器？为每个正在活跃的用户，加载一个布隆过滤器，不喜欢的人，加入过滤器； 后续的推荐列表里，如果布隆过滤器命中，则不推荐，直接尝试推荐下一位；布隆过滤器存在一些误报的问题，概率很低，就当两个人没有缘分。 |
 | 5 HeapOverflow 2021 年 3 月 23 日 via iPhone 为什么不能整一个字典，直接看有没有目标用户的 uid |
 | 6 cxe2v 2021 年 3 月 23 日 查询可用用户列表时候随机查，然后使用者账号这边有个记录了左滑右滑的列表项，在随机查出来的用户列表里如果在这个用户账户下有记录，则跳过这个用户 |
 | 7 monsterxx03 2021 年 3 月 23 日 一般是要提取用户特征, 比如 20 ~ 25 岁, 男性, 注册 7 天内, 爱好 xxx, 根据特征预计算出成百上千个 segment, 用户匹配的时候根据自己的特征去不同的 segment 里抽用户, 选择不喜欢, 可能只是在 userA->userB 的关系里记录一个负权重. 怎么及时得更新 user segment, 用户关系怎么存储都是个技术活, 高度取决于产品和运营策略. sql not in 这种属于学生作业级别操作...有用户量的社交产品不可能这么高 |
 | 8 watzds 2021 年 3 月 23 日 via Android 在客户端去重也行吧，后端同步数据 |
Select Language