在性能开始下降之前,MySQL数据库能有多大

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

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

我的内存已达到10GB,只有少量的连接,它处理的请求也很好。

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

一般来说,这是一个非常微妙的问题,并不是微不足道的。我鼓励你阅读 mysqlperformanceblog.com 和 High Performance MySQL . 我真的认为没有一般的答案。

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

记录的数量很重要,这取决于表的外观。有很多varchar字段或者只有几个int或long是不同的。

数据库的物理大小也很重要:例如,考虑备份。取决于您的引擎,您的物理数据库文件在增长,但不收缩,例如使用innodb。所以删除大量的行并不能帮助您缩小物理文件。

这个问题有很多,而且在很多情况下,魔鬼在细节中。

数据库大小 做事情 . 如果您有超过一百万条记录的多个表,那么性能确实开始下降。记录的数量当然会影响性能: MySQL can be slow with large tables . 如果达到一百万条记录,如果索引设置不正确,则会出现性能问题(例如,联接中的“where语句”或“on条件”字段没有索引)。如果你达到了1000万条记录,即使你的所有指数都正确,你也会开始出现性能问题。硬件升级——增加更多内存和处理器功率,尤其是内存——通常有助于通过再次提高性能(至少在一定程度上)来减少最严重的问题。例如 37 signals went from 32 GB RAM to 128GB of RAM 用于basecamp数据库服务器。

我将首先关注您的索引,而不是让服务器管理员查看您的操作系统,如果所有这些都不起作用,那么可能是进行主/从配置的时候了。

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

->看看 partitioning .

2GB和大约1500万条记录是一个非常小的数据库-我在Pentium III上运行了很多更大的记录!!)一切都还很快…如果你的速度慢,这是一个数据库/应用程序设计问题,而不是一个MySQL问题。

讨论“数据库性能”是毫无意义的,这里“查询性能”是一个更好的术语。答案是:它取决于查询、它操作的数据、索引、硬件等。您可以了解将扫描多少行,以及将使用什么索引和解释语法。

2GB并不算是一个“大型”数据库,它更像是一个中型数据库。

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

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

我曾经被要求查看一个“停止工作”的MySQL。我发现DB文件位于安装了NFS2的网络设备文件管理器上,最大文件大小为2GB。当然,停止接受事务的表在磁盘上正好是2GB。但是在性能曲线方面,我被告知它像冠军一样一直工作到完全不起作用!这段经历对我来说总是一个很好的提醒,那就是在你自然怀疑的那个维度上下总是存在着维度。

需要考虑的一点也是系统的目的和日常数据。

例如,对于一个装有GPS监测车的系统来说,查询数据与前几个月车的位置无关。

因此,可以将数据传递到其他历史表以进行可能的查询,并减少日常查询的执行时间。

我目前正在亚马逊的云基础设施上管理一个MySQL数据库,它已经增长到了160 GB。查询性能良好。备份、恢复、添加从系统,或者处理整个数据集的任何其他操作,甚至大表上的DDL,都是一个噩梦。获取转储文件的干净导入已成为问题。为了使流程足够稳定以实现自动化,需要做出各种选择,以将稳定性优先于性能。如果我们必须使用SQL备份从灾难中恢复,我们将停机几天。

横向扩展SQL也是非常痛苦的,而且在大多数情况下,当您首先选择将数据放入SQL时,会导致以您可能不希望的方式使用它。shard、read slaves、multi master等,它们都是非常糟糕的解决方案,会给您使用DB所做的每件事情增加复杂性,但没有一个解决问题;只是在某些方面减轻了问题。我强烈建议,当您开始接近一个数据集时,将您的一些数据移出MySQL(或任何SQL),在这个数据集的大小上,这些类型的事情会成为一个问题。

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

如果索引正确,请使用正确的引擎(不要在需要多个DML的地方使用myisam),使用分区,根据使用情况分配正确的内存,当然还有良好的服务器配置,mysql甚至可以处理兆兆字节的数据!

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

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

例如,我使用了一个由100000种药物组成的表,该表中的每种药物都有一个列的通用名,其中该列的每种药物的通用名超过15个字符。我放置了一个查询,以便在两个表之间比较药物的通用名。运行该查询需要花费更多的时间。同样,如果使用药物索引比较药物,则使用ID列(如上所述),它将只需要几秒钟。

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