我正在重新设计数据库，我正在构建新表来保存用户上传文件的数据。这里的重叠问题是用户可以上传大量不同类型的文件。例如，他们可能会将mp3文件上传为歌曲，个人资料图片，个人资料封面照片等。但是我遇到了一些设计和实际问题，并且我正在努力找出最好的方法。目前主要设计看起来像这样：
ID | name | type | amazon_S3_info
ID：为每次新上传自动递增ID。
名称：上传名称，例如文件名称
输入：它的上传类型，例如个人资料照片，封面照片，音频文件等。
amazon_S3_info：我将所有文件存储在S3中，此字段包含数据，因此我可以生成URL。我不能在这里存储URL，因为即时通讯使用签名的网址，它们总是需要使用此字段中存储的数据进行重新生成。
在创建这样的表之后，我可以创建匹配的表格，例如，我创建用户ID与他们上传的个人资料图片的上传ID之间的关系等，这非常简单。
我最初的想法是将整个事情分解成多个表格，这意味着我会为个人资料图片制作1个表格，为封面照片制作1个表格等。这个问题在php端会变得有点令人头疼的原因是我有一个标准函数，它使用ID来检索这些文件的文件URL。如果我有多个表，那么每种类型的上传都会有1个相同的ID，从而使我当前的URL检索变得无用。这已经在整个网站上使用，并且会对重做产生麻烦，但是如果它需要它则需要。
要清楚这里分成几张桌子的想法就是速度。我的逻辑是，将一个可能为2,000,000行的表分成4个500,000的表会更有效。从这500,000行表中的每一个中提取数据会更快，还是错误的前提？
所以我的问题很多，哪个数据库设计更好，特别是当我们谈论扩展到相当大的时候？
答案 0 :(得分：3)
对于数据库（以及一般的计算机），您通常会担心10的因素，而不仅仅是2倍或3倍。
因此，按类型将表拆分为多个表，比如说5个表而不是1个表，一旦数据变得非常大，最终将无法解决您的性能问题。就像你说的那样，这是编程的痛苦。 （基本上你是在没有算法的情况下手动进行分片...如果去分片也可以使用散列分片算法来查找数据库/表。）
您拥有的设计是多对多的标准。正确地索引表格，这是你能做的最好的。
如果性能出现问题，则需要水平缩放。关系数据存储区不能很好地完成此任务，但NoSQL数据存储区可以做到这一点。您也可以在NoSQL中使用这些类型的引用。如果仍然可以进行设计更改，请查看AWS DynamoDB（NoSQL服务）。
编辑：回复评论......
@ arian1123根据我的经验，有一点（表大小）突然mysql开始表现不佳。您拥有的硬件（尤其是内存）越多，表格在发生之前就会越大。 （杀手是加入的。如果你不加入大桌子上的大桌子，那么一张大桌子本身可能会因为有足够的硬件而变得非常大，我已经处理了1Billion +行表，其中只有读取是在没有连接的情况下完成的，这不是问题。）
在您自己的笔记本电脑上，您可能会看到100k表表现良好，而1M表表现不佳。如果数据不再增长，那就是你在生产中拥有的硬件的力量，那么拆分将是一个好主意。但是，如果你要总是增加表大小，比如你提到的50M，那么将它拆分只会有助于你能够无限拆分（就像每隔200万行再划分一次表）。在你的情况下，你不想继续将1个表分成4到20到100 ......所以我认为最好留下1个表，如果它没有执行，那么请查看其他表数据存储类型。