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

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

我拥有一个大型数据库，大约有1500万条记录，几乎占了2GB。根据这些数字，是否有激励我清除数据，还是我可以放心地将其继续扩展几年？

解决方案

回答

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

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

我有10GB的内存，连接数量适中，它可以很好地处理请求。

我将首先关注索引，然后让服务器管理员查看OS，如果所有这些都无济于事，那么也许是时候实现主/从配置了。

回答

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

我正在一个项目中，该项目的MySQL数据库包含近1TB的数据。最重要的可伸缩性因素是RAM。如果表的索引适合内存并且查询得到了高度优化，则平均计算机可以为我们提供合理数量的请求。

记录的数量确实很重要，这取决于表的外观。有很多varchar字段或者只有几个int或者longs是不同的。

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

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

回答

还要注意复杂的联接。交易复杂性可能是交易量之外的重要因素。

重构繁重的查询有时可以大大提高性能。

回答

曾经有人要求我查看"已停止工作"的mysql。我发现数据库文件驻留在装有NFS2的Network Appliance文件管理器中，最大文件大小为2GB。可以肯定的是，已停止接受事务的表恰好在磁盘上为2GB。但是关于性能曲线，我被告知它一直像冠军一样工作，直到完全失效为止！这种经历对我而言总是一个很好的提醒，总会存在我们自然怀疑的尺寸之上和之下的尺寸。

回答

谈论"数据库性能"是毫无意义的，"查询性能"在这里是一个更好的术语。答案是：它取决于查询，操作的数据，索引，硬件等。我们可以了解将要扫描多少行以及将使用EXPLAIN语法使用哪些索引。

2GB并不是真正的"大型"数据库，它更多的是中等大小。

回答

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

确实如此。通常起作用的另一件事是只是减少重复使用的数据量。如果我们有"旧数据"和"新数据"，并且99％的查询都使用新数据，则只需将所有旧数据移到另一个表中就可以了；)

->看一下分区。

回答

2GB和大约1500万条记录是一个非常小的数据库，我已经在奔腾III(！)上运行了更大的数据库，并且一切仍然运行得非常快。 。