每个国家我都有很多桌子。我希望每个评论相关的字段，以便用户可以在我的网站上发表评论。我可能还有几个字段，比如：创建注释的日期、注释者的用户id。此外，我可能需要在将来添加其他字段。例如，company_support_comment/support_rating，company_professionality_comment
假设我有100万个公司在一个表中，每个公司有100条评论。然后我得到了很多评论，就一个国家来说，很容易超过20亿。
无符号bigint可以支持18 446 744 073 709 551 615。所以我们可以在一个表中有这么多的注释。无符号整数将给我们42多亿。一张桌子不够。
然而，想象一下查询一个有40亿条记录的表？要多长时间？我可能无法有效地检索注释，这会给数据库带来巨大的负载。在实践中，一张桌子可能做不到。
多个表也可能不好。除非我们只是使用json数据。
实际上我现在还不确定。我需要一个适合我的数据库设计的解决方案。我现在正在使用mysql。
最佳答案
在我看来，你的问题走错了方向。
从数据库设计开始。这意味着，如果你担心的话，可以从bigint开始（因为如果你弄错了，从int转换成bigint会很痛苦）。建立一个良好的规范化模式。然后想办法快点。
在您的例子中，postgresql可能是比mysql更好的选择，因为您的查询很可能是针对辅助索引的。使用innodb的mysql要比postgresql昂贵，因为使用mysql，必须遍历主键索引才能检索行。这意味着，有效地，遍历两个btree索引以获得您要查找的行。也许不是世界末日，但如果你最关心的是业绩，那可能是你不想付出的代价。虽然MySQL覆盖索引在一些情况下更有用，但我不认为它们在这里帮助您，因为您感兴趣的是，实际上，在文本字段中，您可能没有直接索引。
在postgresql中，有一个btree索引，该索引为您提供一系列页/元组元组，然后允许您使用随机访问有效地查找数据。如果有这么大的表，这将是一场胜利，我的经验是，postgresql可以在大表（比如，表的索引大小在2-3tb之间）上很好地执行。
然而，假设你坚持MySQL，仔细注意索引可能会让你在需要去的地方。记住，你只为一个公司拉了100条评论，遍历一个索引有O（log n）复杂度，所以它并不是那么糟糕。最大的问题是遍历检索到的每一行的pkey索引，但即使这样也应该是可管理的。
关于mysql - 正确的大数据数据库设计，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/34847652/