对于“多大的大”问题，没有一个很好的一般解决方案 – 这些问题往往取决于您在使用数据以及您的性能考虑因素。

表格尺寸有一些基本限制。您不能有超过1000列。您的记录不能大于8k。这些限制因数据库引擎而异。 (这些是为InnoDB。)

听起来你已经将几个不同的数据集合并成一个表。你可能有一些字段告诉你这个记录属于什么数据，连同一些数据字段和一些时间戳信息。这不是一个非常广泛的记录(除非您记录每个请求的所有输入参数)。您的主要问题将是选择性。以有意义的方式索引此表将是一个挑战。如果您的公共领域可以有足够的选择性，您可以使用它们来获取所需的记录，而无需咨询表格，这将是一个巨大的加分。 (Cf.表扫描)

对于每天的许多记录(基本上每天都有两秒，而且我假定你的峰值负载时间高得多)，你还要确保你特别看看改进插入的优化速度。作为一般规则，更多的索引=较慢的插入。如果可以，请考虑将过时的记录归档到另一张桌子。在以前的工作场所，我们使用了上个月，前三个月，前六个月的档案策略，每个都在不同的表格中。另一个想法是删除较旧的记录。许多环境根本不需要某个日期之后的信息。从三个月前登录记录往往过于昂贵。

最后，不要忽略你的桌子的物理存储。您的记录越薄，读取(或为此事件插入)记录所需的物理IO越少。您可以将索引存储在单独的物理硬盘驱动器上。如果您的记录中存在大量冗余数据，则压缩的表可能实际上是速度增加。如果您有一点点现金燃烧，请考虑一个良好的RAID阵列的价值来分解数据。

所以，回答你的基本问题：这是很多的记录，但是仔细的调整，这不会是一个问题。