我是数据库系统设计的新手。阅读了很多文章后，我真的很困惑我们应该有 1 个表而不进行分片或分区的限制是多少。我知道提供通用答案确实很困难，事情取决于诸如
之类的因素
- 行的大小
- 数据类型（字符串、blob 等）
- 活跃查询数量
- 什么样的查询
- 索引
- 重读/重写
- 预期延迟
但是当有人问这个问题
- 如果每天有 10 亿条数据和数百万行添加，您会怎么做？对于如此大的数据库，4 次读取、1 次写入和 2 次更新查询的延迟需要低于 5 毫秒。
- 如果您只有 1000 万行，但更新和读取量很高，您会选择什么？添加的新行数并不重要。高一致性、低延迟是要求。
如果行数少于一百万，并且行大小增加数千，那么选择很简单。但当选择涉及数百万或数十亿行时，事情就会变得更加棘手。
注意：我在问题中没有提到延迟数。请
根据您可以接受的延迟数回答。另外，我们正在讨论结构化数据。
我不确定，但我可以添加 3 个具体问题：
- 假设您为亚马逊或任何电子商务订单管理系统选择 SQL 数据库。订单数量每天都在以百万计的速度增长。已经有10亿条记录了。现在，假设没有数据存档。每秒有超过一千个查询的高读取查询。并且也有写入。读：写比例为100：1
- 让我们举一个现在较小的数字的例子。假设您为 abc 或任何电子商务订单管理系统选择 SQL 数据库。订单数量每天都在增加数千。已经有1000万条记录。现在，假设没有数据存档。每秒有超过一万个查询的高读取查询。并且也有写入。读写比例为10:1
- 第三个示例：免费赠品分发。我们有1000万件好东西要分发。每个用户 1 件好东西。高一致性、低延迟是目标。假设已经有 2000 万用户在等待免费分发，一旦时间开始，他们所有人都会尝试获得免费的好东西。
注意：在整个问题中，假设我们将选择
SQL 解决方案。另外，如果提供的用例在逻辑上没有意义，请忽略。目的是获取数字方面的知识。
有人可以帮忙了解一下基准是什么吗？您当前正在从事的项目中的任何实际数字都可以表明，对于具有如此多查询的大型数据库，这就是观察到的延迟。任何可以帮助我证明针对特定延迟的一定数量的查询选择表数量的合理性的任何东西。
MySQL 的一些答案。由于所有数据库都受到磁盘空间、网络延迟等限制，其他引擎可能类似。
SELECT是可能的。所以你需要了解查询是否是这样病态的。 （我认为这是高“延迟”的一个例子。）PARTITIONing（尤其是在 MySQL 中）的用途很少。更多详细信息：分区INDEX对于性能非常重要。每天插入一百万行不是问题。 （当然，有些模式设计可能会导致这个问题。）经验法则：100/秒可能不是问题； 1000/秒可能是可能的；之后就变得更难了。更多关于高速摄取当您进入大型数据库时，它们分为几种不同的类型；每个都有一些不同的特征。
SPATIAL或一些技术 此处