MySQL 数据库从什么时候开始性能下降？
- 物理数据库大小重要吗？
- 记录数量重要吗？
- 性能下降是线性的还是指数的？
我有一个我认为是大型数据库的数据库，大约有 1500 万条记录，占用了将近 2GB 的空间。基于这些数字，我是否有动力清理数据，或者我是否可以安全地让它继续扩展几年？
问问题
206136 次
15 回答
218
物理数据库大小无关紧要。记录的数量无关紧要。
以我的经验，您将遇到的最大问题不是大小，而是您一次可以处理的查询数量。很可能您将不得不迁移到主/从配置，以便读取查询可以针对从属运行，而写入查询可以针对主控运行。但是，如果您还没有为此做好准备，您可以随时调整您正在运行的查询的索引以加快响应时间。此外，您可以对 Linux 中的网络堆栈和内核进行大量调整，这将有所帮助。
我的内存容量高达 10GB，连接数量适中，它处理的请求很好。
我将首先关注您的索引，然后让服务器管理员查看您的操作系统，如果这一切都没有帮助，那么可能是时候实施主/从配置了。
于 2008-08-04T15:26:55.807 回答
104
一般来说，这是一个非常微妙的问题，而不是微不足道的。我鼓励您阅读mysqlperformanceblog.com和High Performance MySQL。我真的认为对此没有一般性的答案。
我正在开发一个项目，该项目有一个 MySQL 数据库，其中包含近 1TB 的数据。最重要的可扩展性因素是 RAM。如果您的表的索引适合内存并且您的查询经过高度优化，那么您可以使用普通机器处理合理数量的请求。
记录的数量确实很重要，具体取决于您的表格的外观。有很多 varchar 字段或只有几个 int 或 long 是不同的。
数据库的物理大小也很重要：例如，考虑备份。根据您的引擎，您的物理数据库文件会增长，但不会缩小，例如使用 innodb。所以删除很多行，无助于缩小你的物理文件。
这个问题有很多，而且在很多情况下，魔鬼在细节中。
于 2008-08-04T18:44:15.690 回答
49
数据库大小确实很重要。如果您有多个表包含超过一百万条记录，那么性能确实开始下降。记录的数量当然会影响性能：MySQL 对于大型表可能会很慢。如果您达到一百万条记录，如果索引设置不正确（例如，“WHERE 语句”或连接中的“ON 条件”中的字段没有索引），则会出现性能问题。如果你达到 1000 万条记录，即使你的所有索引都正确，你也会开始遇到性能问题。硬件升级——增加更多内存和更多处理器能力，尤其是内存——通常至少在一定程度上通过再次提高性能来帮助减少最严重的问题。例如Basecamp 数据库服务器的 37 个信号从 32 GB RAM 变为 128 GB RAM。
于 2012-01-26T10:33:01.050 回答
25
我会首先关注您的索引，而不是让服务器管理员查看您的操作系统，如果这一切都没有帮助，那么可能是时候进行主/从配置了。
确实如此。通常有效的另一件事是减少重复使用的数据量。如果您有“旧数据”和“新数据”，并且 99% 的查询都使用新数据，只需将所有旧数据移动到另一个表 - 不要查看它；）
-> 看看分区。
于 2008-08-11T19:19:05.547 回答
25
我目前在亚马逊的云基础设施上管理一个 MySQL 数据库，该数据库已经增长到 160 GB。查询性能很好。已成为噩梦的是备份、恢复、添加从属设备或任何其他处理整个数据集，甚至是大型表上的 DDL。获得转储文件的干净导入已成为问题。为了使流程足够稳定以实现自动化，需要做出各种选择来优先考虑稳定性而不是性能。如果我们不得不使用 SQL 备份从灾难中恢复，那么我们会瘫痪好几天。
水平扩展 SQL 也非常痛苦，并且在大多数情况下会导致以您最初选择将数据放入 SQL 时可能不打算使用的方式使用它。Shards、read slaves、multi-master 等等，它们都是非常糟糕的解决方案，会增加你对 DB 所做的一切的复杂性，而且没有一个能解决问题；只是在某些方面减轻了它。我强烈建议您在开始处理这些类型的事情成为问题的大小的数据集时，考虑将您的一些数据移出 MySQL（或实际上是任何 SQL）。
更新：几年后，我们的数据集已经增长到大约 800 GiB。此外，我们有一个 200+ GiB 的表，还有一些在 50-100 GiB 范围内的表。我之前所说的一切都成立。它仍然执行得很好，但是运行完整数据集操作的问题变得更糟了。
于 2017-06-30T16:25:34.353 回答
23
2GB 和大约 1500 万条记录是一个非常小的数据库 - 我在 pentium III（！）上运行了更大的记录，而且一切仍然运行得很快。如果你的速度很慢，那是数据库/应用程序设计问题，而不是 mysql一。
于 2010-08-05T09:03:48.627 回答
19
谈论“数据库性能”是没有意义的，“查询性能”在这里是一个更好的术语。答案是：它取决于查询、它所操作的数据、索引、硬件等。您可以了解要扫描的行数以及使用 EXPLAIN 语法将使用哪些索引。
2GB 并不能真正算作“大型”数据库——它更像是一个中等大小的数据库。
于 2008-08-06T19:53:54.580 回答
9
还要注意复杂的连接。除了交易量之外，交易复杂性也是一个重要因素。
重构繁重的查询有时会大大提高性能。
于 2008-08-04T19:01:23.860 回答
9
我曾经被要求查看一个“停止工作”的 mysql。我发现数据库文件驻留在使用 NFS2 安装的 Network Appliance 文件管理器上，最大文件大小为 2GB。果然，停止接受事务的表在磁盘上正好有 2GB。但是关于性能曲线，我被告知它一直像冠军一样工作，直到它根本不起作用！这段经历对我来说总是一个很好的提醒，在你自然怀疑的维度之上和之下总是存在维度。
于 2008-08-06T04:27:52.373 回答
8
需要考虑的一点也是系统的目的和日常数据。
例如，对于具有 GPS 监控汽车的系统，从前几个月的汽车位置查询数据是不相关的。
因此，可以将数据传递到其他历史表以进行可能的查询，并减少日常查询的执行时间。
于 2012-12-06T05:13:30.677 回答
5
如果数据库设计不当，性能可能会下降几千行。
如果你有合适的索引，使用合适的引擎（不要在需要多个 DML 的地方使用 MyISAM），使用分区，根据使用情况分配正确的内存，当然还有良好的服务器配置，MySQL 甚至可以处理 TB 级的数据！
总有一些方法可以提高数据库性能。
于 2013-09-19T11:26:31.763 回答
5
这取决于您的查询和验证。
例如，我使用了一个包含 100 000 种药物的表，该表有一个通用名称列，其中该表中每种药物的字符数超过 15 个。我提出了一个查询来比较两个表之间的药物通用名称。查询需要运行更多分钟。同样，如果您使用药物索引比较药物，使用 id 列（如上所述），只需几秒钟。
于 2016-11-29T12:05:24.577 回答
1
数据库大小在字节和表的行数方面确实很重要。您会注意到轻量级数据库和填充 blob 的数据库之间存在巨大的性能差异。一旦我的应用程序卡住了，因为我将二进制图像放在字段中，而不是将图像保存在磁盘上的文件中，并且只将文件名放在数据库中。另一方面，迭代大量行并不是免费的。
于 2017-06-05T10:27:47.113 回答
0
不，这并不重要。MySQL 的速度约为每秒 700 万行。所以你可以扩展它
于 2019-05-25T09:18:46.853 回答
0
查询性能主要取决于它需要扫描的记录数，索引在其中起着很大的作用，索引数据大小与行数和索引数成正比。
带有索引字段条件和完整值的查询通常会在 1ms 内返回，但starts_with、IN、Between 显然包含条件可能需要更多时间扫描更多记录。
此外，您将面临许多 DDL 维护问题，例如 ALTER、DROP 会很慢且很难处理更多实时流量，即使添加索引或新列也是如此。
一般来说，建议将数据库集群到尽可能多的集群中（500GB 将是一个通用基准，正如其他人所说，它取决于许多因素，并且可能因用例而异），这样它可以提供更好的隔离并提供独立于规模特定集群（更适合 B2B 的情况）
于 2020-06-14T14:10:10.887 回答