您提到在 SQL 查询中执行此操作，因此我将在其中提供示例。
如果您有表/视图Pages，像这样的
Pages
-----
page_id:int
views:int - indexed
comments:int - indexed
然后你可以通过写来订购它们
SELECT * FROM Pages
ORDER BY
(0.3+LOG10(10+views)/LOG10(10+(SELECT MAX(views) FROM Pages))) +
(0.7+LOG10(10+comments)/LOG10(10+(SELECT MAX(comments) FROM Pages)))
我故意在观点和评论之间选择了不平等的权重。与视图/评论保持相同的权重可能出现的一个问题是，排名变成了一个自我实现的预言——一个页面返回到列表的顶部，因此它的访问频率更高，从而获得更多的分数，所以它是显示在列表的末尾，并且访问次数更频繁，并且获得更多积分......对评论给予更多重视反映了这些评论需要真正的努力并表现出真正的兴趣。
上面的公式将为您提供基于历史统计数据的排名。因此，上周积累的浏览量/评论数与去年另一篇文章积累的浏览量/评论数相同的文章将获得相同的优先级。重复该公式可能是有意义的，每次指定日期范围，并优先考虑活动较高的页面，例如
0.3*(score for views/comments today) - live data
0.3*(score for views/comments in the last week)
0.25*(score for views/comments in the last month)
0.15*(score for all views/comments, all time)
这将确保“热门”页面比最近没有太多操作的类似评分页面获得更高的优先级。除了今天的分数之外的所有值都可以通过计划的存储过程保留在表中，以便数据库不必聚合许多评论/视图统计信息。只有今天的统计数据是“实时”计算的。更进一步，排名公式本身可以通过每天运行的存储过程来计算和存储历史数据。
编辑：要获得从 0.1 到 1.0 的严格范围，您可以像这样设计公式。但我强调 - 这只会增加开销并且是不必要的 - 优先级的绝对值并不重要 - 只有它们与其他 url 的相对值。搜索引擎使用这些来回答以下问题：URL A 是否比 URL B 更重要/相关？它通过比较它们的优先级（哪一个是最大的）而不是它们的绝对值来做到这一点。
// 非标准化 - x 是某个页面 id
un(x) = 0.3*log(观看次数(x)+10)/log(10+最大观看次数()) +
0.7*log(评论数(x)+10)/log(10+最大评论数())
// 原始公式（现在是伪代码）
最大值将为 1.0，最小值将从 1.0 开始，并随着更多视图/评论的增加而向下移动。
我们定义un(0)为最小值，即（上式中views(x)和comments(x)均为0）
要获得从 0.1 到 1.0 的标准化公式，您需要计算 n(x)，即页面的标准化优先级x
(1.0-un(x)) * (un(0)-0.1)
n(x) = un(x) - ------------------------- when un(0) != 1.0
1.0-un(0)
= 0.1 otherwise.
