为非常大的基于时间的数据集选择正确的MySQL结构

Question

过去的几个月我一直在使用MySQL，并且对小型数据库结构有很好的了解。但是，现在，我需要决定如何创建一个数据库，该数据库可以在多个表或单个表中存储大量面向时间的数据。

使用单个表，我尝试将其划分为每年的段，但是，加载时间和插入时间仍然很长。特别是对于搜索。数据由大约8000个报告站组成，每天约有300-500个报告（每小时几个）。这些报告可以追溯到1980年，因此很容易超过1.2亿个数据点并在不断增长。

我不确定什么可以为搜索如此大量的数据提供最佳结果，或者将数据分成多个表是否更好。每个报告只有几列信息（时间，温度和风）。

我确信这个问题已经问了很多遍了，但是任何帮助都将不胜感激。

谢谢！

Answer 1

1.2亿行足以容纳PARTITIONing。而且对于基于时间的数据 if 很有用，您需要删除“旧”数据。这是因为DROP PARTITION比DELETE更快，侵入性更小。

我将在here进行详细讨论。

加载到已分区表中的速度应该比未分区表稍慢（在极少数情况下更快）。

搜索问题-听起来您没有正确索引表。一些提示：

• （通常）将“分区键”放在所有索引的最后，如果需要的话。
• 仅使用PARTITION BY RANGE(TO_DAYS(...))。
• 40年了？ 40个分区是合理的。
• 不要按station进行分区，但是可能在某些索引的开头使用该列。
• 请告诉我CREATE TABLE，以便我在提示中更具体。
• 如果您不打算删除“旧”行，那么分区可能是一种浪费。让我们来看一些查询。
• 另一方面，如果您经常使用日期范围和多个测站，则将遇到“ 2D索引问题”。按年份划分；以PRIMARY KEY开始station

不要不要使用多个表。这是该论坛上的常见问题，答案始终相同。

很可能您需要某种“汇总表”。它可能包括每个周的高温，低温，平均温度等。例如，对于多年温度图表来说，这显然是7倍的速度。更多here。

仅插入37行/秒应该不是问题，即使在慢速的HDD上也是如此。如果它们成批出现，则可以通过每个INSERTs语句的多行或INSERT来批量LOAD DATA。