在性能开始下降之前 MySQL 数据库可以有多大

Posted 2023-02-16

【中文标题】在性能开始下降之前 MySQL 数据库可以有多大

【英文标题】：How big can a MySQL database get before performance starts to degrade

【发布时间】：2010-09-05 07:15:15

【问题描述】：

mysql 数据库从什么时候开始性能下降？

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

我有一个大型数据库，大约有 1500 万条记录，占用了将近 2GB。根据这些数字，我是否有动力清理数据，或者我是否可以安全地让它继续扩展几年？

【参考方案1】：

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

水平扩展 SQL 也非常痛苦，并且在大多数情况下，会导致以您最初选择将数据放入 SQL 时可能不打算使用的方式使用它。 Shards、read slaves、multi-master 等等，它们都是非常糟糕的解决方案，它们增加了你对 DB 所做的一切的复杂性，而且没有一个能解决问题；只是在某些方面减轻了它。我强烈建议您在开始处理这些类型的事情成为问题的大小的数据集时，考虑将一些数据移出 MySQL（或实际上是任何 SQL）。

更新：几年后，我们的数据集已增长到大约 800 GiB。此外，我们有一个 200+ GiB 的表，还有一些在 50-100 GiB 范围内的表。我之前所说的一切都成立。它仍然执行得很好，但是运行完整数据集操作的问题变得更糟了。

【讨论】：

把它从 MySQL.. 移出另一个 MySQL？

进入非关系数据存储。关系数据库基本上不会在不停机或破坏关系模型的情况下进行扩展。如果您要破坏关系模型，最好停止使用关系数据库。相反，创建专门构建的文档并将它们放入文档存储引擎中，例如 CouchDB 或其他系统。

【参考方案2】：

查询性能主要取决于它需要扫描的记录数，索引在其中起着重要作用，索引数据大小与行数和索引数成正比。

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

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

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

【参考方案3】：

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

【讨论】：

你有这方面的资料吗？

我们不要忘记每秒插入次数取决于您拥有的机器类型（CPU 功率和磁盘速度）。在我的非正式测试中，我看到在蹩脚的笔记本电脑上每秒插入 100 次左右，在更强大的基于 SSD 的笔记本电脑上每秒插入多达 2000 次。换句话说，这是一个假设且不可靠的指标。

【参考方案4】：

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

【参考方案5】：

一般来说，这是一个非常微妙的问题，而不是微不足道的。我鼓励您阅读mysqlperformanceblog.com 和High Performance MySQL。我真的认为对此没有一般性的答案。

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

记录数确实很重要，具体取决于您的表格的外观。有很多 varchar 字段或只有几个 int 或 long 是不同的。

数据库的物理大小也很重要：例如，考虑备份。根据您的引擎，您的物理数据库文件会增长，但不会缩小，例如使用 innodb。所以删除很多行，对缩小物理文件没有帮助。

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

【参考方案6】：

我会首先关注您的索引，而不是让服务器管理员查看您的操作系统，如果这一切都没有帮助，那么可能是时候进行主/从配置了。

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

-> 看看partitioning。

【参考方案7】：

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

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

【参考方案8】：

数据库大小很重要。如果您有多个表包含超过一百万条记录，那么性能确实开始下降。记录数当然会影响性能：MySQL can be slow with large tables。如果您达到一百万条记录，如果索引设置不正确（例如，“WHERE 语句”或连接中的“ON 条件”中的字段没有索引），则会出现性能问题。如果你达到 1000 万条记录，即使你的所有索引都正确，你也会开始遇到性能问题。硬件升级——增加更多内存和更多处理器能力，尤其是内存——通常至少在一定程度上通过再次提高性能来帮助减少最严重的问题。例如 37 signals went from 32 GB RAM to 128GB of RAM 用于 Basecamp 数据库服务器。

【参考方案9】：

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

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

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

【参考方案10】：

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

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

我的最大容量为 10GB，连接数适中，它处理的请求很好。

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

【讨论】：

如果数据库大小大于 7 GB 怎么办。事实上，时间限制没有受到影响？

【参考方案11】：

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

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

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

【参考方案12】：

2GB 和大约 1500 万条记录是一个非常小的数据库 - 我在 pentium III（！）上运行了更大的数据库（！），一切仍然运行得很快。如果你的速度很慢，那是数据库/应用程序设计问题，不是一个mysql的。

【参考方案13】：

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

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

【参考方案14】：

我曾经被要求查看一个“停止工作”的 mysql。我发现数据库文件驻留在使用 NFS2 安装的 Network Appliance 文件管理器上，最大文件大小为 2GB。果然，停止接受事务的表在磁盘上正好有 2GB。但是关于性能曲线，我被告知它一直像冠军一样工作，直到它根本不起作用！这段经历对我来说总是一个很好的提醒，总有高于和低于你自然怀疑的维度。

【讨论】：

虽然扩展问题最好从整体上看待，但这与 MySQL 本身的扩展方式完全无关。

【参考方案15】：

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

重构繁重的查询有时会大大提升性能。