我将顶视图和“喜欢”存储在一个名为“计数”的表中。我每晚运行一次这个查询
UPDATE `counts` SET rank=d7+d6+d5+d4+d3+d2+d1,d7=d6,d6=d5,d5=d4,d4=d3,d3=d2,d2=d1,d1=0
一周中的每一天都有一个 d1-d7 变量,我们每晚将其“向下”移动一个并重新计算总和。
随着我网站的发展,这个查询现在需要大约 20 分钟。
我正在寻找有关如何更有效地组织它的建议,因为它似乎是一种常见的模式。
我将顶视图和“喜欢”存储在一个名为“计数”的表中。我每晚运行一次这个查询
UPDATE `counts` SET rank=d7+d6+d5+d4+d3+d2+d1,d7=d6,d6=d5,d5=d4,d4=d3,d3=d2,d2=d1,d1=0
一周中的每一天都有一个 d1-d7 变量,我们每晚将其“向下”移动一个并重新计算总和。
随着我网站的发展,这个查询现在需要大约 20 分钟。
我正在寻找有关如何更有效地组织它的建议,因为它似乎是一种常见的模式。
正如评论所说,我们需要查看架构。但无论如何我都会提出一个建议。没有 7 个不同的字段 d1-d7。如果以后您决定将分数保持一年以上怎么办?哎哟。
我将假设counts
它view_id
的PK。然后有另一个ranks
包含列的表view_id
(设置为 FK 到counts
),rank
(概括 d1-d7,无论它们是什么数据类型)和rank_date
,这是一个日期。现在每晚你都有
UPDATE counts SET rank = (SELECT SUM(rank) FROM ranks r WHERE r.view_id=counts.view_id
AND r.rank_date>=DATE_SUB(CURDATE(), INTERVAL 1 WEEK) );
[某些 RDBMS 允许在 UPDATE 查询中使用 JOIN 类型的语法。我相信 MySQL 理解类似于以下内容,但它不是我常用的 RDBMS
UPDATE counts, (SELECT view_id, SUM(rank) AS srank FROM ranks r
WHERE r.rank_date>=DATE_SUB(CURDATE(), INTERVAL 1 WEEK)
GROUP BY r.view_id) AS q1
SET rank = srank
WHERE counts.view_id=q1.view_id;
]
如果是这样,那可能会比第一个版本运行得更快。
同时,可选择清理,您可以删除ranks
超过 1 周的行,但在更灵活的模式中,您不必这样做。