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

Translate

MySQL数据库什么时候开始失去性能?

  • 物理数据库的大小重要吗?
  • 记录数量重要吗?
  • 性能下降是线性的还是指数的?

我拥有一个大型数据库,大约有1500万条记录,几乎占用2GB。根据这些数字,是否有激励我清理数据,还是我可以安全地将其继续扩展几年?

This question and all comments follow the "Attribution Required."

所有的回答

Translate

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

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

我有10GB的内存,连接数量适中,它可以很好地处理请求。

我将首先关注您的索引,然后让服务器管理员查看您的OS,如果所有这些都无济于事,那么也许是时候实现主/从配置了。

来源
Translate

总的来说,这是一个非常微妙的问题,并非微不足道。我鼓励你阅读mysqlperformanceblog.com高性能MySQL。我真的认为对此没有普遍的答案。

我正在一个项目中,该项目的MySQL数据库包含近1TB的数据。最重要的可伸缩性因素是RAM。如果表的索引适合内存并且查询得到了高度优化,则平均计算机可以为您提供合理数量的请求。

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

数据库的物理大小也很重要:例如,考虑备份。根据您的引擎,您的物理数据库文件会增长,但不会缩小,例如使用innodb。因此,删除很多行无助于缩小物理文件。

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

来源
Translate

数据库大小确实很重要。如果您有多个表且记录数超过一百万,则性能确实开始下降。记录的数量当然会影响性能:MySQL对于大型表可能会变慢。如果您达到一百万条记录,那么如果索引设置不正确(例如,联接中“ WHERE语句”或“ ON条件”中的字段没有索引),则会遇到性能问题。如果您达到1000万条记录,即使您所有的索引都正确,也将开始出现性能问题。硬件升级-添加更多的内存和更多的处理器能力,尤其是内存-通常可以通过至少在一定程度上提高性能来帮助减少最严重的问题。例如37个信号从32 GB RAM变为128GB RAM用于Basecamp数据库服务器。

来源
Translate

我将首先关注您的索引,而不是让服务器管理员查看您的OS,如果所有这些都无济于事,那可能是时候进行主/从配置了。

确实如此。通常起作用的另一件事是只是减少重复使用的数据量。如果您有“旧数据”和“新数据”,并且99%的查询都使用新数据,则只需将所有旧数据移动到另一个表中即可-无需查看;)

->看看分割.

来源
ian
Translate

2GB和大约1500万条记录是一个非常小的数据库-我已经在pentium III(!)上运行了更大的记录,并且一切仍然运行得非常快。如果您的记录很慢,则是数据库/应用程序设计问题,而不是mysql一。

来源
Translate

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

2GB并没有真正算作“大型”数据库-它更多的是中等大小。

来源
Translate

还要注意复杂的联接。交易复杂性可能是交易量之外的重要因素。

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

来源
Translate

曾经有人要求我查看“已停止工作”的mysql。我发现这些数据库文件驻留在装有NFS2且最大文件大小为2GB的Network Appliance文件管理器中。可以肯定的是,已停止接受事务的表恰好是2GB磁盘。但是关于性能曲线,我被告知它一直像冠军一样工作,直到根本不起作用为止!这项经验始终为我提供了一个很好的提醒,那就是总是存在您自然怀疑的尺寸之上和之下的尺寸。

来源
Translate

还需要考虑的一点是系统的用途以及每天的数据。

例如,对于具有汽车GPS监视功能的系统而言,前几个月来自汽车位置的查询数据不相关。

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

来源
Translate

我目前正在管理Amazon云基础架构上的MySQL数据库,该数据库已增长到160 GB。查询性能很好。成为噩梦的是备份,还原,添加从属服务器,或处理整个数据集甚至是大型表上的DDL的任何其他操作。干净导入转储文件已成为问题。为了使过程足够稳定以实现自动化,需要做出各种选择来优先考虑稳定性而不是性能。如果我们曾经不得不使用SQL备份从灾难中恢复,那么我们将连续几天陷入困境。

水平扩展SQL也是很痛苦的,在大多数情况下,导致您最初选择将数据放入SQL时可能会以意想不到的方式使用它。分片,读取从属服务器,多主服务器等,它们都是很糟糕的解决方案,它们增加了您对DB所做的一切的复杂性,而没有一个解决问题。仅在某种程度上减轻了它。我强烈建议您在开始处理大小可能会成为问题的数据集时,考虑将一些数据移出MySQL(或实际上是任何SQL)。

来源
Translate

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

如果您有合适的索引,请使用合适的引擎(不要在多个DML的情况下使用MyISAM),使用分区,根据使用情况分配正确的内存,并且当然具有良好的服务器配置,MySQL甚至可以处理TB级的数据!

总有提高数据库性能的方法。

来源
Translate

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

例如,我使用了一个包含100000种药物的表,该表具有一列通用名称,该表中每种药物的名称都超过15个字符。我提出了一个查询来比较两个表之间的药物通用名称。同样,如果您使用药物索引,使用id列(如上所述)比较药物,则只需几秒钟。

来源
Translate

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

来源
Translate

不,这并不重要。 MySQL的速度约为每秒700万行。所以你可以扩展很多

来源