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

Gra*_*ant 292 mysql database database-performance

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

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

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

Nic*_*rdi 198

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

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

我有我的高达10GB,只有中等数量的连接,它处理请求就好了.

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


dli*_*sin 82

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

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

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

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

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


0x4*_*672 41

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


Bla*_*laM 23

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

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

- >看看分区.


小智 21

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


dea*_*mer 18

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

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


sai*_*eon 9

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

重构大量查询有时会带来很大的性能提升.


jj3*_*j33 9

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

  • 虽然从整体上看,缩放问题是最好的,但这与MySQL本身的扩展方式完全无关. (3认同)

ald*_*tis 9

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

例如,对于具有GPS监控汽车的系统,与前几个月的汽车位置不相关的查询数据.

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


Ric*_*mer 8

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

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

  • 进入非关系数据存储。如果没有停机或破坏关系模型,关系数据库从根本上就无法扩展。如果您要破坏关系模型,最好停止使用关系数据库。相反,创建专门构建的文档并将其放入文档存储引擎中,例如 CouchDB 或其他系统。 (2认同)

小智 5

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

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

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


Ana*_*s23 5

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

例如,我使用了一个包含 100 000 种药物的表,该表有一个通用名称列,其中该表中每种药物的字符超过 15 个。我放置了一个查询来比较两个表之间的药物通用名称。查询需要运行更多分钟。同样,如果您使用药物索引比较药物,使用 id 列(如上所述),只需几秒钟。