我有一张桌子，每分钟大约有 10-15k 个条目。每一个都标有进入时的当前时间戳。该表是MEMORY 表，因为丢失数据不是问题。
每分钟，我都有一个运行以下查询的脚本：
DELETE FROM tracker WHERE post_time < DATE_SUB(NOW(), INTERVAL 15 MINUTE)
这个查询运行大约需要 1-2 秒，这还不错，但似乎这种类型的查询（删除所有早于X 的内容）在针对MEMORY 表。它还对 CPU 有一个相应的尖峰，每分钟都像拇指酸痛一样伸出来。
我可以对我的查询进行任何优化以更有效地运行此查询吗？
【问题讨论】：
标签： mysql performance
与往常一样，您应该查看查询计划并将其发布在此处。你可以通过发出EXPLAIN DELETE FROM tracker WHERE post_time < DATE_SUB(NOW(), INTERVAL 15 MINUTE) 来做到这一点
现在，问题很可能是 DELETE 查询不能使用索引，并且必须遍历所有行。
即使你已经在 post_time 上有一个索引，它也可能不会被使用，因为 MEMORY 表上的默认索引是哈希索引。
哈希索引只能用于相等性检查，不能用于post_time < DATE_SUB(NOW(), INTERVAL 15 MINUTE)等范围
在您的 post_time 列上创建 BTREE 索引，
CREATE INDEX post_time_idx ON tracker (post_time) USING BTREE;
【讨论】：
在 post_time 上建立索引。如果匹配 post_time < DATE_SUB(NOW(), INTERVAL 15 MINUTE) 的行是整个表的一小部分，这应该会加快速度。
【讨论】：
如果您的表中的数据从不超过 15 分钟，您可以使用比 DATETIME 更小的数据类型来存储您的时间戳。根据您关心的粒度，您可能会使用 非常 小数据类型...使用 SMALLINT 您可以存储“自午夜以来的分钟数”。如果您愿意失去更多的粒度，您可以使用 TINYINT 来获得 15 分钟的粒度。当然，这需要稍微复杂一点的逻辑，来处理“午夜过后”的案件......
DELETE FROM tracker
WHERE (
EXTRACT(DAY_MINUTE FROM NOW()) > 15
AND post_time < EXTRACT(DAY_MINUTE FROM NOW())
) OR (
post_time < EXTRACT(DAY_MINUTE FROM NOW()) < 15
AND post_time < EXTRACT(DAY_MINUTE FROM NOW()+60)
)
优点是你必须读取和比较的数据要小得多，因此可以更快地处理。如果您将数据存储在磁盘 I/O 比内存带宽更重要的磁盘上，这将产生更大的影响。
此外，对于只有 10-15k 行和适当索引的表，我怀疑这会产生任何明显的差异——无论是在磁盘上还是在内存中。
【讨论】：