在性能开始下降之前,MySQL数据库能达到多少?

mysql database database-performance

170725 观看

14回复

8532 作者的声誉

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

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

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

作者: Grant 的来源 发布者: 2008 年 8 月 4 日

回应 (14)


197

46849 作者的声誉

决定

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

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

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

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

作者: Nick Berardi 发布者: 04.08.2008 03:26

81

11581 作者的声誉

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

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

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

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

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

作者: dlinsin 发布者: 04.08.2008 06:44

9

4207 作者的声誉

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

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

作者: saint_groceon 发布者: 04.08.2008 07:01

9

6238 作者的声誉

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

作者: jj33 发布者: 06.08.2008 04:27

18

5462 作者的声誉

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

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

作者: deadprogrammer 发布者: 06.08.2008 07:53

23

17419 作者的声誉

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

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

->看一下分区

作者: BlaM 发布者: 11.08.2008 07:19

21

219 作者的声誉

2GB和大约1500万条记录是一个非常小的数据库-我已经在奔腾III(!)上运行了更大的记录,并且一切仍然运行得非常快。一。

作者: ian 发布者: 05.08.2010 09:03

41

17345 作者的声誉

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

作者: 0x4a6f4672 发布者: 26.01.2012 10:33

9

2928 作者的声誉

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

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

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

作者: alditis 发布者: 06.12.2012 05:13

5

145 作者的声誉

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

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

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

作者: Abhijit Buchake 发布者: 19.09.2013 11:26

3

413 作者的声誉

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

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

作者: Anands23 发布者: 29.11.2016 12:05

2

130 作者的声誉

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

作者: Viktor Joras 发布者: 05.06.2017 10:27

8

1103 作者的声誉

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

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

作者: Rich Remer 发布者: 30.06.2017 04:25

0

23 作者的声誉

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

作者: getNordic 发布者: 25.05.2019 09:18
32x32