对于MySQL表来说，多大才算太大？

Question

我最终被说服将我的小表放到一个大表中，但是对于一个MySQL表来说，到底多大才算大呢？

我有一个包含18个字段的表。有些是TEXT，有些是short VARCHAR(16)，有些是longer VARCHAR(100)。

现在，我们每天收到大约200,000行数据，相当于一个月6个million+。多大才算太大？你有多少个字段很重要，还是只有几行？

Answer 1

对于“多大才是太大”这个问题，没有一个很好的通用解决方案--这类问题通常取决于您正在对数据做什么以及您的性能考虑因素是什么。

表的大小有一些基本限制。列数不能超过1000列。每个记录不能超过8k。这些限制根据数据库引擎的不同而不同。(这里的代码是针对InnoDB的。)

听起来您已经将几个不同的数据集合并到一个表中。您可能有一些字段告诉您此记录属于哪个数据集，以及一些数据字段和一些时间戳信息。这不是一个很宽的记录(除非您记录每个请求的所有输入参数)。您的主要问题将是选择性。以一种有意义的方式索引这个表将是一个挑战。如果您的公共字段具有足够的选择性，您可以使用它们来获取您想要的记录，而无需查询表，这将是一个巨大的优势。(请参阅表扫描)

对于每天这么多的记录(基本上是每秒两个，我假设您有一个峰值负载时期，那里的记录要高得多)，您还需要确保专门关注提高插入速度的优化。一般来说，更多的索引=更慢的插入。如果可以，可以考虑将过期记录完全归档到另一个表中。在以前的工作环境中，我们使用了“上个月”、“前三个月”、“前六个月”的归档策略，每个都在单独的表中。另一个想法是删除较旧的记录。许多环境根本不需要超过某个日期的信息。保留三个月前的日志记录通常代价过高。

最后，不要忽略表的物理存储。记录越薄，读取(或插入)记录所需的物理IO就越少。您可以将索引存储在单独的物理硬盘上。如果您的记录中有大量冗余数据，则存储表的压缩实际上可能会提高速度。如果你有一些钱要花，考虑一个好的RAID阵列对你的数据进行条带化的价值。

所以，回答你的基本问题:它有很多记录，但是仔细考虑调优，它不会是问题。

Answer 2

我有一个大约有98M行的表，插入/删除操作整天都在进行。我们保存了90天的记录...我预计这个表这个月大约有100M行。就我个人而言，我会以不同的方式设计数据库模式，但它是购买的，我们需要保持它的完整性，这样我们就不会使任何供应商的支持失效。

我们使用mysql复制(MASTER-MASTER)，在一个上执行插入/删除操作，在另一个上执行查询。这确实有助于提高性能，因为在我们改用复制之前，删除操作会锁定表和块查询。

使用这个实现，我们没有遇到任何性能问题。

我还每周执行一次表优化...

Answer 3

基本上，我认为这要看情况。您使用的是哪个版本的MySQL，使用的是什么操作系统，使用的是MyISAM表还是innoDB表？它也是different on 32-bit and 64-bit，并且根据您的日志设置而有所不同。MySQL manual说：

MySQL数据库的有效最大表大小通常由操作系统对文件大小的约束决定，而不是由MySQL内部限制决定

在该页面上也有关于这些限制的更多细节。