在性能开始下降之前，MySQL数据库可以达到多大

小开

最佳答案

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

根据我的经验，您将遇到的最大问题不是大小，而是您一次可以处理的查询数量。最有可能的是，您将不得不转移到主/从配置，以便读查询可以在从服务器上运行，写查询可以在主服务器上运行。但是，如果您还没有准备好这样做，您可以随时为正在运行的查询调整索引，以加快响应时间。此外，您可以对Linux中的网络堆栈和内核进行很多调整，这将有所帮助。

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

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

小开

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

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

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

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

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

小开

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

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

小开

我曾经被叫去查看一个mysql，它已经“停止工作”。我发现DB文件位于用NFS2挂载的Network Appliance文件中，最大文件大小为2GB。果然，停止接受事务的表在磁盘上正好是2GB。但关于性能曲线，我被告知它一直工作得很好，直到它根本无法工作!这种经历总是提醒我，总有一些维度高于或低于你自然怀疑的维度。

小开

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

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

小开

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

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

看一下分区。

小开

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

小开

数据库大小很重要。如果您有多个表，其中包含超过一百万条记录，那么性能确实会开始下降。记录的数量当然会影响性能:MySQL在处理大表时速度很慢。如果有一百万条记录，如果索引设置不正确，就会出现性能问题(例如，在“WHERE语句”或连接中的“ON条件”中没有字段索引)。如果有1000万条记录，即使所有的索引都是正确的，也会出现性能问题。硬件升级——增加更多内存和更强大的处理器能力，尤其是内存——通常有助于通过再次提高性能来减少最严重的问题，至少在一定程度上是这样。例如，Basecamp数据库服务器的37个信号从32gb RAM变成128GB RAM。

小开

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

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

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

小开

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

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

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

小开

这取决于您的查询和验证。

例如，我处理过一个包含10万种药物的表格，表格中每个药物都有一个超过15个字符的列通用名。我输入了一个查询来比较两个表格之间药物的通用名。查询需要更多的时间来运行。同样，如果使用药物索引，使用id列(如上所述)比较药物，只需要几秒钟。

小开

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

小开

我目前在亚马逊的云基础设施上管理一个MySQL数据库，这个数据库已经增长到160 GB。查询性能良好。已经成为噩梦的是备份、恢复、添加从数据集或任何其他处理整个数据集，甚至是大型表上的DDL。对转储文件进行干净的导入已经成为问题。为了使流程足够稳定以实现自动化，需要做出各种选择，优先考虑稳定性而不是性能。如果我们必须使用SQL备份从灾难中恢复，那么我们可能要宕机好几天。

水平扩展SQL也是相当痛苦的，在大多数情况下，当您选择将数据放入SQL时，可能会以一种意想不到的方式使用它。shard, read slave, multi-master等等，它们都是非常糟糕的解决方案，给你在DB上做的所有事情都增加了复杂性，而且没有一个能解决问题;只是在某种程度上减轻了它。我强烈建议，当您开始处理这些类型的事情成为问题的大数据集时，考虑将一些数据移出MySQL(或任何SQL)。

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

小开

不，这并不重要。MySQL的速度大约是每秒700万行。所以你可以把它放大一点

小开

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

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

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

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