问题描述

MySQL 数据库从什么时候开始性能下降?

At what point does a MySQL database start to lose performance?

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

我有一个我认为的大型数据库，大约有 1500 万条记录，占用了近 2GB.根据这些数字，是否有任何动机让我清理数据，或者我是否可以安全地让它继续扩展几年?

I have what I believe to be a large database, with roughly 15M records which take up almost 2GB. Based on these numbers, is there any incentive for me to clean the data out, or am I safe to allow it to continue scaling for a few more years?

推荐答案

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

The physical database size doesn't matter. The number of records don't matter.

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

In my experience the biggest problem that you are going to run in to is not size, but the number of queries you can handle at a time. Most likely you are going to have to move to a master/slave configuration so that the read queries can run against the slaves and the write queries run against the master. However if you are not ready for this yet, you can always tweak your indexes for the queries you are running to speed up the response times. Also there is a lot of tweaking you can do to the network stack and kernel in Linux that will help.

我的容量高达 10GB，只有中等数量的连接，它可以很好地处理请求.

I have had mine get up to 10GB, with only a moderate number of connections and it handled the requests just fine.

我会首先关注您的索引，然后让服务器管理员查看您的操作系统，如果所有这些都无济于事，那么可能是时候实施主/从配置了.

I would focus first on your indexes, then have a server admin look at your OS, and if all that doesn't help it might be time to implement a master/slave configuration.

这篇关于在性能开始下降之前 MySQL 数据库可以有多大的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！