I once was called upon to look at a mysql that had "stopped working". I discovered that the DB files were residing on a Network Appliance filer mounted with NFS2 and with a maximum file size of 2GB. And sure enough, the table that had stopped accepting transactions was exactly 2GB on disk. But with regards to the performance curve I'm told that it was working like a champ right up until it didn't work at all! This experience always serves for me as a nice reminder that there're always dimensions above and below the one you naturally suspect.

物理数据库大小无关紧要。记录的数量并不重要。

In my experience the biggest problem that you are going to run in to is not size, but the number of queries you can handle at a time. Most likely you are going to have to move to a master/slave configuration so that the read queries can run against the slaves and the write queries run against the master. However if you are not ready for this yet, you can always tweak your indexes for the queries you are running to speed up the response times. Also there is a lot of tweaking you can do to the network stack and kernel in Linux that will help.

我的内存达到了10GB，只有中等数量的连接，它处理请求还不错。

我将首先关注您的索引，然后让服务器管理员查看您的操作系统，如果所有这些都没有帮助，那么可能是时候实现主/从配置了。

2GB和约15M条记录是一个非常小的数据库-我在奔腾III上运行过更大的数据库(!)，一切仍然运行得非常快。如果你的慢，那是数据库/应用程序设计的问题，而不是mysql的问题。

总的来说，这是一个非常微妙的问题，无论如何都不是微不足道的。我建议你阅读mysqlperformanceblog.com和高性能MySQL。我真的认为这个问题没有普遍的答案。

我正在做一个项目，它有一个MySQL数据库，几乎有1TB的数据。最重要的可伸缩性因素是RAM。如果您的表的索引适合内存，并且您的查询得到了高度优化，那么您可以使用普通机器处理合理数量的请求。

记录的数量确实很重要，这取决于表的外观。有很多varchar字段和只有几个int或long类型是有区别的。

数据库的物理大小也很重要:例如，考虑备份。根据你的引擎，你的物理db文件会增长，但不会缩小，例如innodb。因此，删除大量的行，并不有助于缩小您的物理文件。

这个问题有很多，在很多情况下，细节决定成败。

查询性能主要取决于它需要扫描的记录数，索引在其中起着很高的作用，索引数据大小与行数和索引数成正比。

带有索引字段条件和完整值的查询通常会在1毫秒内返回，但是starts_with, in, Between，显然包含条件可能需要更多的时间和更多的记录来扫描。

此外，您还将面临DDL的许多维护问题，如ALTER, DROP将缓慢且难以处理更多的实时流量，即使是添加索引或新列。

一般来说，建议将数据库集群到所需的尽可能多的集群中(500GB将是一个通用的基准，正如其他人所说，它取决于许多因素，并且可以根据用例而变化)，这样可以提供更好的隔离性，并提供扩展特定集群的独立性(更适合B2B情况)

The database size does matter. If you have more than one table with more than a million records, then performance starts indeed to degrade. The number of records does of course affect the performance: MySQL can be slow with large tables. If you hit one million records you will get performance problems if the indices are not set right (for example no indices for fields in "WHERE statements" or "ON conditions" in joins). If you hit 10 million records, you will start to get performance problems even if you have all your indices right. Hardware upgrades - adding more memory and more processor power, especially memory - often help to reduce the most severe problems by increasing the performance again, at least to a certain degree. For example 37 signals went from 32 GB RAM to 128GB of RAM for the Basecamp database server.