我将存储像用户这样的东西;搜索历史，发布观看历史记录，保存的帖子等...您明白了。
例如，对于用户保存的帖子，用户在整个生命周期内将拥有大约500-2,000，并且有数千名用户可以看到这将如何快速加起来..所以当用户希望看到他们保存时发布历史记录显示它的最佳方式是什么？
Surley在桌子上查找与用户ID匹配的所有已保存帖子（大约2,000个）会很疯狂（如果我以传统方式存储它（用户，postid））！
我有一个想法是将所有用户保存在一个大型数组中的post ID，因此每个用户将有1行而不是2,000（存储在一个单元格中）。我有什么理由不这样做吗？你知道什么是最有效的方法？哦，如果你同意这是什么数据类型，BLOB？
附带问题 - 当数据库达到超过10-100万行的大小时，大多数人会采用什么解决方案？ （硬件除外）
答案 0 :(得分：0)
按建议添加索引。 1亿行的可能解决方案是一种称为数据库分片的技术，您可以根据ID范围在多个数据库实例（服务器）中有效地封送同一个表。然后，给定用户的帖子将存在于许多“分片”中的一个