mySQL-如何缓存选定结果/提高大数据性能的最佳方法

因此，我正在开发一个系统，在特定的时间范围内以可视方式显示数据。
为了显示数据，将使用HuuUuge数据集执行复杂的查询（可能甚至超过100万条记录）

有些查询不会更改（显然，因为在此时间范围内不会收集更多数据）。我们已经设置了一个分区系统，但当我们想收集6个月以上的数据时，问题就出现了。-在一年（1000+*365+）以上的时间范围内，每天计算一段时间（每个记录1000次）将导致严重的性能问题

~

最初，我想为每个独特的查询创建一个表，并具有一个收集和存储当天数据的功能（每天凌晨1点左右定期执行）。
所以我会有一张原本看起来像这样的桌子：

---------------------------------------------------
| Item  | StartTime | EndTime | Column1 | Column2 |
---------------------------------------------------
| Item1 | Day1      | Day1    | DataA1  | DataB2  |
| Item2 | ...       | ...     | DataA1  | DataB4  |
| Item1 | ...       | ...     | DataA2  | DataB4  |
| ...   | ...       | ...     | ...     | ...     |
| Item1 | Day2      | Day2    | DataA1  | DataB2  |
| Item2 | ...       | ...     | DataA1  | DataB4  |
| Item1 | ...       | ...     | DataA2  | DataB4  |
| ...   | ...       | ...     | ...     | ...     |
---------------------------------------------------

+-----------------------------------------------------------------------------+
| Date  | Item   | AvgTime | MaxTime | OtherComplex | OtherComplex2 | ....... |
|-------+--------+---------+---------+--------------+---------------+---------|
| Day1  | Item1  | 45.22   | 120     | abcdef       | ABCDEF        | ...     |
| ...   | Item2  | ...     | ...     | ...          | ...           | ...     |
| ...   | ...    | ...     | ...     | ...          | ...           | ...     |
| ...   | ...    | ...     | ...     | ...          | ...           | ...     |
| Day2  | Item1  | 16.02   | 24      | defghi       | ABCDEF        | ...     |
| ...   | Item2  | ...     | ...     | ...          | ...           | ...     |
| ...   | ...    | ...     | ...     | ...          | ...           | ...     |
| ...   | ...    | ...     | ...     | ...          | ...           | ...     |
+-----------------------------------------------------------------------------+

它附加了如下数据：

---------------------------------------------------
| Item  | StartTime | EndTime | Column1 | Column2 |
---------------------------------------------------
| Item1 | Day1      | Day1    | DataA1  | DataB2  |
| Item2 | ...       | ...     | DataA1  | DataB4  |
| Item1 | ...       | ...     | DataA2  | DataB4  |
| ...   | ...       | ...     | ...     | ...     |
| Item1 | Day2      | Day2    | DataA1  | DataB2  |
| Item2 | ...       | ...     | DataA1  | DataB4  |
| Item1 | ...       | ...     | DataA2  | DataB4  |
| ...   | ...       | ...     | ...     | ...     |
---------------------------------------------------

+-----------------------------------------------------------------------------+
| Date  | Item   | AvgTime | MaxTime | OtherComplex | OtherComplex2 | ....... |
|-------+--------+---------+---------+--------------+---------------+---------|
| Day1  | Item1  | 45.22   | 120     | abcdef       | ABCDEF        | ...     |
| ...   | Item2  | ...     | ...     | ...          | ...           | ...     |
| ...   | ...    | ...     | ...     | ...          | ...           | ...     |
| ...   | ...    | ...     | ...     | ...          | ...           | ...     |
| Day2  | Item1  | 16.02   | 24      | defghi       | ABCDEF        | ...     |
| ...   | Item2  | ...     | ...     | ...          | ...           | ...     |
| ...   | ...    | ...     | ...     | ...          | ...           | ...     |
| ...   | ...    | ...     | ...     | ...          | ...           | ...     |
+-----------------------------------------------------------------------------+

我相信这是可行的，但是我们必须维护更多的表——如果我们想在程序中添加更多的功能，那么维护起来可能会很困难

我们可以使用，但我相信这指的是带有“静态”变量的静态数据的查询——系统的很大一部分是我们可以在任意两个日期之间进行查询

~

---

那么，最好的解决办法是什么呢？欢迎任何建议。

100万条记录离Huuuge数据集相去甚远。您可能需要优化您的模式和/或索引。在尝试优化错误之前发布解释选择[…]结果stuff@sathia这是对将要使用的查询进行解释选择的结果。请注意，这仅适用于一个时段，查询长度约为100行（另外364行需要显示每天的数据）。-收集的数据仅针对一个用户，大约5天的数据。我们预计数据至少要大2000倍。看起来您没有使用基数更大的索引。我看到您已经模糊了一些字段，但是如果您能够粘贴查询并显示相关表的create table输出，这将非常有帮助。不管怎样，一个100行长的查询通常表明有一些东西可以优化