Answers:
物理数据库的大小无关紧要。记录的数量无关紧要。
以我的经验，您将要遇到的最大问题不是大小，而是一次可以处理的查询数。最有可能的是，您将不得不转向主/从配置，以便可以对从服务器运行读查询，而对主服务器运行写查询。但是，如果您还没有做好准备，可以随时为正在运行的查询调整索引，以加快响应时间。另外，您可以对Linux中的网络堆栈和内核进行大量调整，这将有所帮助。
我有多达10GB的内存，而且连接数量适中，它可以很好地处理请求。
我将首先关注您的索引，然后让服务器管理员查看您的OS，如果所有这些都无济于事，那么也许是时候实现主/从配置了。
总的来说，这是一个非常微妙的问题，并非微不足道。我鼓励您阅读mysqlperformanceblog.com和High Performance MySQL。我真的认为对此没有普遍的答案。
我正在一个项目中，该项目的MySQL数据库包含近1TB的数据。最重要的可伸缩性因素是RAM。如果表的索引适合内存并且查询得到了高度优化，则平均计算机可以为您提供合理数量的请求。
记录的数量确实很重要，这取决于表的外观。有很多varchar字段或只有几个int或longs是不同的。
数据库的物理大小也很重要：例如，考虑备份。根据您的引擎，您的物理数据库文件会增长，但不会缩小，例如使用innodb。因此，删除很多行无助于缩小物理文件。
这个问题有很多，在很多情况下，细节是魔鬼。
数据库的大小确实很重要。如果您有多个表且记录数超过一百万，则性能确实开始下降。记录的数量当然会影响性能：MySQL对于大型表可能会很慢。如果您达到一百万条记录，那么如果索引设置不正确（例如，联接中“ WHERE语句”或“ ON条件”中的字段没有索引），则会遇到性能问题。如果您达到1000万条记录，即使您所有的索引都正确，也将开始遇到性能问题。硬件升级-添加更多的内存和更多的处理器能力，尤其是内存-通常可以通过至少在一定程度上再次提高性能来帮助减少最严重的问题。例如对于Basecamp数据库服务器，从32 GB RAM到128GB RAM有37个信号。
我目前正在管理Amazon云基础架构上的MySQL数据库，该数据库已增长到160 GB。查询性能很好。噩梦是备份，还原，添加从属或其他任何与整个数据集有关的事情，甚至涉及大型表上的DDL。干净导入转储文件已成为问题。为了使过程足够稳定以实现自动化，需要做出各种选择以优先考虑稳定性而不是性能。如果我们曾经不得不使用SQL备份从灾难中恢复，那么我们将连续几天陷入困境。
水平伸缩SQL也是很痛苦的，在大多数情况下，导致您选择将数据最初放在SQL中时可能不希望使用它。分片，读取从属服务器，多主服务器等，它们都是很糟糕的解决方案，它们增加了您对DB所做的一切的复杂性，而没有一个解决问题。仅在某些方面减轻了它。我强烈建议您在开始处理这类问题成为问题的大小的数据集时，考虑将一些数据移出MySQL（或实际上是任何SQL）。
还要注意复杂的联接。交易复杂性可能是交易量之外的重要因素。
重构繁重的查询有时可以大大提高性能。
如果数据库设计不当，性能可能会下降几千行。
如果您有适当的索引，请使用适当的引擎（不要在预期使用多个DML的情况下使用MyISAM），使用分区，根据用途分配正确的内存，并且当然具有良好的服务器配置，MySQL甚至可以处理TB级的数据！
总有提高数据库性能的方法。
数据库大小确实取决于字节和表的行数。您会注意到，轻量级数据库和填充的blob之间存在巨大的性能差异。一旦我的应用程序卡住，是因为我将二进制图像放在字段中，而不是将图像保留在磁盘上的文件中，而仅将文件名放在数据库中。另一方面，迭代大量的行不是免费的。
查询性能主要取决于它需要扫描的记录数，索引在其中扮演着重要的角色，索引数据的大小与行数和索引数成正比。
具有索引字段条件以及完整值的查询通常会在1毫秒内返回，但是starts_with，IN，Bweens显然包含条件可能需要花费更多时间来扫描更多记录。
同样，您将面临DDL的许多维护问题，例如ALTER，DROP将会变得缓慢且困难，即使添加索引或新列，实时流量也会增加。
通常建议将数据库群集到所需的尽可能多的群集中（500GB是一个通用基准，正如其他人所说，它取决于许多因素，并且可以根据使用情况而有所不同），这样可以更好地隔离并提供针对特定规模的独立性集群（更适合B2B）