如何处理快速增长的 MySQL 表？

问题描述

我有一个名为 transactions 的表，如下所示：

id | user_id | business_id | amount | tracking_code | status | created_at | updated_at

如您所见，这是一个保存所有交易的表。目前它有超过 5000 万行，每天大约有 4000 行新行被添加到其中。我担心未来一两年业务规模扩大，最终我会得到一张非常大的桌子。

目前我们在这个表上有两个索引以获得更好的搜索性能。引擎也是 innodb。

知道一般应该如何处理吗？

在硬件资源方面，我完全可以在需要时增加服务器硬件。但我想，未来的问题将是管理数据，而不是资源。

解决方法

磁盘空间很便宜。你有什么，3.2 GB 的数据和索引中的一些因素。如果应用程序不需要所有数据都在线，那么您可以选择存档旧数据（转储然后从表中删除）。您可以查看 compression 作为一个选项。可能与某些 alternative storage engines

,

我不会担心在可以将索引保存在内存中的机器上有 10 亿行的应用程序性能。

但是，如果您知道表正在快速增长，我建议将 id 列设为 BigInt，因为 32 位整数将被限制为 2^31-1= 2,147,483,647 行

您的表格和搜索引擎的性能取决于：

1. 这些查询对这个特定表有多少联接？
2. 您的索引设置得如何？显然不错
3. 托管数据库的机器有多少 RAM？
4. 速度和与之相关的处理器数量？
5. 查询中返回的行大小/数据量。

,

不要担心有多少 CPU 和它们的速度。这很少是 MySQL 中的限制因素。

您需要created_at还是updated_at？

不要理会压缩；这不太值得。

在实际（和保守）的情况下，请使用较小的数据类型。

坚持使用 InnoDB。原因有很多；此处不再赘述。

请向我们展示 SHOW CREATE TABLE 和一些重要的查询。我们可能会有更多提示。