I'm currently managing a MySQL database on Amazon's cloud infrastructure that has grown to 160 GB. Query performance is fine. What has become a nightmare is backups, restores, adding slaves, or anything else that deals with the whole dataset, or even DDL on large tables. Getting a clean import of a dump file has become problematic. In order to make the process stable enough to automate, various choices needed to be made to prioritize stability over performance. If we ever had to recover from a disaster using a SQL backup, we'd be down for days.

Horizontally scaling SQL is also pretty painful, and in most cases leads to using it in ways you probably did not intend when you chose to put your data in SQL in the first place. Shards, read slaves, multi-master, et al, they are all really shitty solutions that add complexity to everything you ever do with the DB, and not one of them solves the problem; only mitigates it in some ways. I would strongly suggest looking at moving some of your data out of MySQL (or really any SQL) when you start approaching a dataset of a size where these types of things become an issue.

更新:几年后，我们的数据集已经增长到大约800 GiB。此外，我们还有一个200+ GiB的表和其他一些50-100 GiB的表。我之前说的都成立。它的性能仍然很好，但运行完整数据集操作的问题变得更糟了。

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.

数据库大小确实与字节数和表的行数有关。您将注意到light数据库和blob填充数据库之间的巨大性能差异。有一次我的应用程序卡住了，因为我把二进制图像放在字段中，而不是把图像保存在磁盘上的文件中，只把文件名放在数据库中。另一方面，迭代大量的行并不是免费的。

还有一点需要考虑的是系统和数据在日常生活中的用途。

例如，对于一个用GPS监控汽车的系统来说，查询汽车前几个月的位置数据是不相关的。

因此，可以将数据传递给其他历史表，以便进行可能的查询，并减少日常查询的执行次数。

谈论“数据库性能”有点毫无意义，“查询性能”在这里是一个更好的术语。答案是:这取决于查询，它所操作的数据，索引，硬件等。您可以了解将要扫描多少行，以及使用EXPLAIN语法将使用哪些索引。

2GB并不算真正的“大”数据库——它更像是一个中等大小的数据库。

如果数据库设计不当，性能可能会在几千行中下降。

如果你有合适的索引，使用合适的引擎(不要使用MyISAM，因为需要多个dml)，使用分区，根据使用情况分配正确的内存，当然还有良好的服务器配置，MySQL可以处理tb级的数据!

总有办法提高数据库性能。