我终于确信将我的小表放到一个大表中，但对于MySQL表来说究竟有多大？
我有一张包含18个字段的表格。有些是TEXT，有些是短VARCHAR(16)，有些是VARCHAR(100)。
现在我们每天大约有20万行，每月600万+。有多大太大了？你有多少个字段或只是行？
答案 0 :(得分：15)
对于“有多大太大”的问题，没有一个很好的通用解决方案 - 这些问题通常取决于您对数据的处理以及您的性能考虑因素。
表格大小有一些基本限制。您不能超过1000列。您的记录不能超过每个8k。这些限制根据数据库引擎而变化。 （这里的是InnoDB。）
听起来你已将几个不同的数据集合并到一个表中。您可能有一些字段可以告诉您此记录所属的数据集，以及一些数据字段和一些时间戳信息。这不是一个非常广泛的记录（除非您记录，例如，每个请求的所有输入参数。）您的主要问题是选择性。以有意义的方式为此表编制索引将是一项挑战。如果您的公共字段具有足够的选择性，您可以使用它们来获取所需的记录而无需查阅表格，这将是一个巨大的优势。 （参见表扫描）
对于每天的那么多记录（基本上，一整天都是两秒，而且我假设你的峰值负载时间要高得多），你还要确保你专门看一下优化提高插入速度。作为一般规则，更多索引=插入速度较慢。如果可以，请考虑将过时的记录完全归档到另一个表。在之前的工作场所，我们使用了上个月，前三个月，前六个月的档案策略，每个策略都在不同的表格中。另一个想法是删除旧记录。许多环境根本不需要超过特定日期的信息。挂在三个月前记录的记录往往过于昂贵。
最后，不要忽视表格的物理存储空间。记录越薄，读取（或就此而言，插入）记录所需的物理IO就越少。您可以将索引存储在单独的物理硬盘驱动器上。如果您的记录中存在大量冗余数据，则存储压缩的表实际上可能是速度增加。如果你有一点点现金可以燃烧，可以考虑一个好的RAID阵列的值，用于条带化数据。
所以，回答你的基本问题：这是很多记录，但仔细考虑调整，这不会是一个问题。
答案 1 :(得分：2)
我认为这基本上取决于。您使用的是哪个版本的MySQL，操作系统是什么，以及您使用的是MyISAM或innoDB表吗？它也是different on 32-bit and 64-bit，并且根据您的日志记录设置而有所不同。 MySQL manual说：
有效的最大表格大小 通常会确定MySQL数据库 通过操作系统约束 文件大小，而不是MySQL内部 限制
关于这些限制在该页面上的内容还有更多详细信息。
答案 2 :(得分：2)
我有一个包含~98M行的表，并且整天都会插入/删除。我们保留了90天的记录...我希望这个表本月可以达到~100M行。就个人而言，我本来会以不同的方式设计数据库模式，但它已被购买，我们需要保持原样，以便我们不会使任何供应商支持无效。
我们正在使用mysql复制（MASTER-MASTER）并在一个＆amp;上执行插入/删除操作。在另一方执行查询。这确实有助于提高性能，因为删除会在我们更改为使用复制之前锁定表并阻止查询。
我们使用此实现时没有遇到任何性能问题。
我还每周执行一次表格优化...
答案 3 :(得分：0)
选择放入单个表中的列数也取决于所表示的数据类型以及您对规范化的关注程度。有些关系很容易用一个表来表示;其他需要在多个较小的表中完成，尤其是当您在数据集中混合使用一对一，一对多和多对多类型关系时。
答案 4 :(得分：0)
不是确切问题的答案......
为什么你说服你把小桌子放到一张大桌子里？ 您正在做的事情被称为“垂直分区”，实际上可能非常有用，具体取决于您的情况。对于许多大型TEXT或BLOB字段，垂直分区可以使您查询的数据更加物理化，并且访问速度更快。
请参阅：http://en.wikipedia.org/wiki/Partition_(database）
垂直分区涉及创建包含较少列的表，并使用其他表来存储其余列。规范化还涉及在表之间拆分列，但垂直分区超出了这一范围，即使已经规范化，也会对列进行分区。也可以使用不同的物理存储来实现垂直分区;例如，在不同设备上存储不常使用或非常宽的列是一种垂直分区的方法。显式或隐式地完成此类分区称为“行拆分”（该行由其列拆分）。垂直分区的一种常见形式是在表中分割（慢速查找）动态数据（快速查找）静态数据，其中动态数据不像静态那样频繁使用。在两个新创建的表上创建视图会恢复原始表的性能损失，但是在访问静态数据时性能会提高，例如：用于统计分析
另请参阅：http://dev.mysql.com/tech-resources/articles/performance-partitioning.html
答案 5 :(得分：0)
考虑您需要对表格执行的操作。如果桌子纯粹是为了实现，你永远不需要改变它的结构或任何东西。如果您需要它进行数据挖掘，您可能会改变其结构。例如，尝试在其副本上执行alter table。一旦达到临时表变大以存储在内存中的水平，预计此函数会降低性能。
我一直处于相同的情况，数据量使我无法修改数据库的结构。您应该做什么 RIGHT NOW 是要求某人在机器（即EC2实例）上创建一个数据库，其中包含您希望在两年内获得的数据量。让他们以相同的表格格式创建虚假数据。尝试使用此表并确定性能是否可接受。如果不可接受，您需要尽快更改内容。
如果我是你，我会考虑测试Greenplum或（GridSQL，如果你没有钱花钱）。两者都基于PostgreSQL并使用许多计算机一起工作。