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

时间:2008-08-04 14:31:11

标签: mysql database database-performance

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

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

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

14 个答案:

答案 0 :(得分:191)

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

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

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

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

答案 1 :(得分:79)

总的来说,这是一个非常微妙的问题,并不是无关紧要的。我们建议您阅读mysqlperformanceblog.comHigh Performance MySQL。我真的认为没有一般的答案。

我正在开发一个项目,该项目拥有一个拥有近1TB数据的MySQL数据库。最重要的可扩展性因素是RAM。如果表的索引适合内存并且您的查询经过高度优化,则可以使用普通计算机提供合理数量的请求。

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

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

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

答案 2 :(得分:23)

  

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

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

- >看看partitioning

答案 3 :(得分:20)

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

答案 4 :(得分:18)

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

2GB实际上并不算作“大”数据库 - 它更像是一个中等大小。

答案 5 :(得分:9)

我曾经被要求查看一个“停止工作”的mysql。我发现数据库文件驻留在安装了NFS2且最大文件大小为2GB的Network Appliance文件管理器上。果然,已停止接受事务的表在磁盘上正好是2GB。但是就性能曲线而言,我被告知它一直像冠军一样工作直到它根本不起作用!这种体验总是对我有用,这是一个很好的提醒,总是在你自然怀疑的那个上下。

答案 6 :(得分:9)

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

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

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

答案 7 :(得分:9)

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

重构大量查询有时可以大大提升性能。

答案 8 :(得分:8)

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

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

答案 9 :(得分:4)

如果数据库设计不当,性能会在几千行中降低。

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

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

答案 10 :(得分:3)

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

例如,我使用了一个包含10 000种药物的表格,这些药物具有列通用名称,其中该表中每种药物的字符数超过15个。我提出了一个查询来比较两个表格之间药物的通用名称。查询需要更长的时间才能运行。同样,如果使用药物索引比较药物,使用id列(如上所述),只需几秒钟。

答案 11 :(得分:2)

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

答案 12 :(得分:0)

查询性能主要取决于它需要扫描的记录数,索引在其中扮演着重要的角色,索引数据的大小与行数和索引数成正比。

带有索引字段条件以及完整值的查询通常会在1ms内返回,但是starts_with,IN,Bweens显然包含条件可能需要花费更多时间来扫描更多记录。

此外,您将面临DDL的许多维护问题,例如ALTER,DROP将会变得缓慢且困难,即使增加索引或新列,也带来更多实时流量。

通常建议将数据库群集到所需的多个群集中(500GB将是一个通用基准,正如其他人所说,它取决于许多因素,并可能因使用案例而异),这样可以更好地隔离并提供独立性扩展特定集群(更适合B2B)

答案 13 :(得分:0)

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