我终于被说服将我的小表放在一个大表中，但是对于 MySQL 表来说到底多大才算太大？
我有一个包含 18 个字段的表格。有些是 TEXT，有些是短的 VARCHAR(16)，有些是较长的 VARCHAR(100)。
现在我们每天大约有 200,000 行，这将是每月超过 600 万行。多大才算太大？有多少字段或只有行是否重要？
最佳答案
对于“多大才算太大”这个问题没有一个很好的通用解决方案 - 此类问题通常取决于您对数据的处理方式以及您对性能的考虑。
表格大小有一些基本限制。列数不能超过 1000。您的记录不能大于 8k。这些限制因数据库引擎而异。 (这里是 InnoDB 的。)
听起来您已经将几个不同的数据集合并到一个表中。您可能有一些字段可以告诉您此记录所属的数据集，以及一些数据字段和一些时间戳信息。这不是一个非常广泛的记录(除非您记录每个请求的所有输入参数。)您的主要问题将是 选择性。以有意义的方式索引该表将是一个挑战。如果您的公共(public)字段可以有足够的选择性，您可以使用它们来获取您想要的记录而无需查阅表格，那将是一个巨大的优势。 (参见表扫描)
对于每天这么多的记录(基本上，全天每秒两次，我假设您有一个高峰期，它要高得多)，您还需要确保您专门查看优化关于提高插入速度。作为一般规则，更多的索引 = 更慢的插入。如果可以，请考虑将过时的记录完全归档到另一个表中。在以前的工作场所中，我们使用了上个月、前三个月、前六个月的存档策略，每个都在单独的表格中。另一个想法是删除旧记录。许多环境根本不需要超过特定日期的信息。保留三个月前的日志记录通常过于昂贵。
最后，不要忽视 table 的物理存储。您的记录越薄，读取(或就此而言，插入)记录所需的物理 IO 就越少。您可以将索引存储在单独的物理硬盘驱动器上。如果存储压缩表的记录中有大量冗余数据，实际上可能会提高速度。如果您有一点现金可以烧掉，请考虑一个好的 RAID 阵列对数据 strip 化的值(value)。
所以，回答您的基本问题:记录很多，但仔细调整调整，这不是问题。
关于mysql - MySQL 表有多大？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4406417/