优化移动窗口 MYSQL 查询答案

【问题标题】：Optimizing a moving window MYSQL query优化移动窗口 MYSQL 查询
【发布时间】：2011-12-09 17:53:15
【问题描述】：

我有一个MEMORY MYSQL 数据库，其中包含一个包含 200k+ 行的表。我使用这个数据库来测试交易策略，所以它被反复查询，令人作呕。没有新数据添加到数据库中。

此数据库主表中的一列是“时间”。在每个查询中，我的存储过程都会选择那些“时间”最多在查询输入“时间”之前或之后 2 小时的行。

由于我的数据库中的数据具有 5 分钟的分辨率，因此共有 288 个可能的“一天中的时间”(24 * 60/5 = 288)。

这意味着每个查询大致选择表的1/288。此外，这意味着查询 A 和查询 B 之间存在巨大的重叠（紧随其后）。

此时，只有 1 个巨大的表在每个查询中被过滤。这（太）慢了。

我一直在尝试找出更优化的设置。我考虑过创建 288 个预过滤表，并在查询时简单地访问它们。但是，这会占用太多 RAM，最终会减慢查询速度而不是加快查询速度。

还有更优化的解决方案吗？

【问题讨论】：

假设您在右列上有基本的东西，如索引等。您是否检查过查询计划如何查看它是否按照您的预期使用索引。你有足够的内存来保存整个数据库吗？如果要交换磁盘，那么它不会比基于磁盘的表快

【解决方案1】：

您可以简单地在表中添加一个整数列，以指示事务位于哪个“窗口”。因此，对于需要在一次性更新中更新的每条记录，该字段将保存一个介于 1 和 288 之间的值.

之后查询表将是：

select * from mytable where window = 123

例如。必须为此列添加索引。

话虽如此，如果这比仅查询日期列（当然假设已经被索引）执行得更好，我会感到惊讶，但可能值得一试。

过滤具有单个字段索引的 200k 行表确实应该非常快。您是否验证过延迟是由数据库引擎引起的，而不是由检索结果引起的？

【讨论】：

这是个好主意，我会试一试。慢，我的意思是 0.1 秒。就我而言，这很慢。
@Mike 在问题中提及您对慢的定义可能很有用。 stackoverflow 上的很多问题都是新手提出的，所以当你说慢时，通常人们会考虑 10 秒到几分钟的时间