mysql之前的数据库_在性能开始降低之前，MySQL数据库有多大

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

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

物理数据库大小是否重要？

记录数量是否重要？

任何性能下降是线性还是指数？

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

13个解决方案

178 votes

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

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

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

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

Nick Berardi answered 2019-02-17T17:56:05Z

74 votes

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

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

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

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

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

dlinsin answered 2019-02-17T17:56:58Z

37 votes

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

0x4a6f4672 answered 2019-02-17T17:57:24Z

22 votes

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

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

- ＆GT; 看看分区。

BlaM answered 2019-02-17T17:58:02Z

19 votes

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

ian answered 2019-02-17T17:58:27Z

17 votes

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

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

deadprogrammer answered 2019-02-17T17:58:58Z

9 votes

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

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

saint_groceon answered 2019-02-17T17:59:29Z

9 votes

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

jj33 answered 2019-02-17T17:59:54Z

9 votes

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

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

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

alditis answered 2019-02-17T18:00:32Z

6 votes

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

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

Rich Remer answered 2019-02-17T18:01:05Z

4 votes

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

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

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

Abhijit Buchake answered 2019-02-17T18:01:43Z

3 votes

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

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

Anands23 answered 2019-02-17T18:02:15Z

2 votes

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

Viktor Joras answered 2019-02-17T18:02:40Z