还要注意复杂连接。除了交易量之外，交易复杂性也是一个很大的因素。

重构繁重的查询有时会大大提高性能。

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

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

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

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

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

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

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

这是真的。另一个通常有效的方法是减少重复处理的数据量。如果你有“旧数据”和“新数据”，并且99%的查询都使用新数据，只需将所有旧数据移动到另一个表中-并且不要查看它;)

->看看分区。

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

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

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

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