在性能开始降低之前,MySQL数据库可以获得多大的性能?

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

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

我有我认为是一个大型数据库,大约有15M的记录占用了将近2GB。根据这些数字,我是否有动力清理数据,或者我可以安全地让它继续扩展几年?

0

13 答案

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

根据我的经验,您要运行的最大问题不是规模,而是您一次可以处理的查询数量。很可能你将不得不移动到主/从配置,以便读取查询可以针对从服务器运行,并且写查询针对主服务器运行。但是,如果您尚未做好准备,您可以随时调整您正在运行的查询的索引,以加快响应速度。还有很多你可以对Linux中的网络堆栈和内核进行调整,这将有所帮助。

我已经得到了10GB,只有中等数量的连接,它处理请求就好了。

我将首先关注索引,然后让服务器管理员查看您的操作系统,如果所有这些都无助于实现主/从配置。

0
额外
如果数据库大小大于7 GB,怎么办?在这个事实上,时限不受影响?
额外 作者 Hacker,

还要注意复杂的连接。除交易量外,交易复杂性可能是一个重要因素。

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

0
额外

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

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

0
额外

我会首先关注你的索引,而不是让服务器管理员查看你的操作系统,如果所有这些都无助于它,可能是主/从配置的时间。

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

-> Have a look at partitioning.

0
额外

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

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

记录的数量很重要,具体取决于您的表的外观。拥有大量的varchar字段或者只有几个整数或长整数是不同的。

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

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

0
额外

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

例如,对于具有GPS监控汽车的系统而言,与前几个月汽车位置的查询数据无关。

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

0
额外

我曾经被要求查看一个“停止工作”的mysql。我发现数据库文件位于安装有NFS2且最大文件大小为2GB的Network Appliance Filer上。当然,已停止接受事务的表在磁盘上恰好为2GB。但是关于性能曲线,我被告知它像一个冠军一样工作,直到它根本不工作!这种体验总是为我提供一个很好的提醒,即在自然怀疑的那个上面和下面总是有尺寸的。

0
额外
虽然缩放问题最好从整体上来看,但这与MySQL本身如何扩展完全无关。
额外 作者 Lie Ryan,

2GB和大约15M记录是一个非常小的数据库 - 我在奔腾III(!)上运行了更大的一些,并且一切仍然运行得非常快。如果你的速度很慢,这是数据库/应用程序设计问题,而不是MySQL一。

0
额外

如果数据库设计不正确,性能可能会在几千行的情况下降级。

如果你有合适的索引,请使用适当的引擎(不要使用MyISAM,其中需要多个DML),使用分区,根据使用情况分配正确的内存,当然也有良好的服务器配置,MySQL甚至可以以兆兆字节处理数据!

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

0
额外

It depends on your query and validation.

例如,我使用了一张有10万种药物的表格,它有一个列通用名称,该表格中的每种药物都有超过15个字符。我提出了一个查询来比较两个表格之间的药物通用名称。更多的时间运行。同样,如果您使用药物索引比较药物,使用id列(如上所述),则只需要几秒钟。

0
额外

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

0
额外

目前,我正在管理亚马逊云基础架构上的MySQL数据库,该数据库已增长到160 GB。查询性能很好。成为噩梦的是备份,恢复,添加奴隶或其他处理整个数据集的任何内容,甚至是大型表上的DDL。获取转储文件的干净导入已成为问题。为了使过程稳定到足以实现自动化,需要做出各种选择来优先考虑稳定性而不是性能。如果我们必须使用SQL备份从灾难中恢复过来,那么我们会停下来好几天。

水平扩展SQL也是非常痛苦的,并且在大多数情况下,导致按照您选择首先将数据放入SQL中时可能不想要的方式使用它。碎片,读取奴隶,多主人等等,它们都是非常糟糕的解决方案,它们增加了您对数据库所做的一切的复杂性,而且它们中的任何一个都不能解决问题;只是以某种方式减轻它。我强烈建议您在开始处理大小的数据集时,将某些数据从MySQL(或者任何SQL)移出来,这些数据集会导致这些类型的事情成为问题。

0
额外