mysql - 在亚线性时间内从MySQL表中选择加权随机条目

Question

我看到有人主张使用类似于从表中选择随机项的方法。然而，这对我来说似乎非常低效，因为在排序之前，我们必须遍历整个表并为每个表生成随机数。plenty似乎更像是朝着正确的方向迈出了一步：假设总的和是预先计算好的，现在我们得到了一个简单的线性搜索。
不过，确实有可能做得更好，但想到的方法似乎都需要粗略的操作。
我们可以存储一个累积的权重分布，生成一个介于0和max之间的随机数SELECT * FROM tbl ORDER BY -LOG(RAND())/weights LIMIT 1;，并使用weights上的索引和weights来查找帖子。但是，删除或移动中间的条目需要大量的工作来更新之后的权重。
我们可以将表分解成更小的表并计算其中的权重之和。我们首先搜索这些范围，直到找到包含所选随机数的范围，然后对该表执行线性搜索。然而，对于大型BETWEEN有这么多表似乎是糟糕的数据库设计，理想情况下，我希望将其降到对数时间而不是sqrt(n)。
我已经在这个问题上挣扎了一段时间了，这是我想出的最好的办法。还有其他想法吗？

Answer 1

让我试着大声思考。
最好的方法应该确定地为范围（0,1）中的每个值选择特定的条目。对于重量为零的条目，应保留零。
为了使项目1成为可能，每个条目都应该知道其在0到1之间的下限和上限。这正是你在可能的解决方案中所说的。你还说这将意味着许多工作在一个入口重量变化。但不管怎样，你需要重新调整权重，使其总和为1，或者更新并缓存所有权重的总和，以便计算每个权重的百分比。嗯，你说得对，如果你重新调整第一个和最后一个条目之间的权重，你就必须更新这两个条目之间的限制。
这就引出了一个解决方案，在运行时计算极限（下限或上限，实际上只需要一个），将权重相加到条目。好消息是，您可以使用权重覆盖索引，即从内存中读取权重值。
这种方法的缺点是查询的执行时间将取决于随机值：值越多，查询花费的时间就越长。但是，更大权重的范围将更频繁地匹配，所以我们可能会利用这样的事实：权重是在btree索引中排序的，从末尾强制索引查找，在找到值时短循环退出处理（虽然还不确定，这对于积累值的查询是可能的）。
我应该多想一想。
升级1。我刚刚意识到我所描述的和链接答案中写的完全一样。考虑到查询将从索引中获取权重，解决方案应该足够快。当然，还有一个更快的选择方案，但需要更多的空间和准备。这可能看起来很疯狂，但也有可能奏效的情况。您可以将权重分布描述为一个固定的int值范围，并维护一个（内存）表，其中包含从该范围到特定加权项的任何int值的映射。然后查询将一个随机值舍入为int，int值（作为内存表中的主键）将指向某个条目id。显然，表中的行数将取决于权重的粒度，并且在任何权重更新之后都必须更新整个表。但如果重量更新很少，这可能是一个选择。
升级版2。我决定展示一些SQL。下面是两个可行的解决方案。我们有一张桌子：

CREATE TABLE entries (
  entry_id int(10) unsigned NOT NULL AUTO_INCREMENT,
  weight float NOT NULL DEFAULT 0.,
  data varchar(50),
  PRIMARY KEY (entry_id) USING BTREE,
  KEY weights (weight) USING BTREE
) ENGINE=InnoDB;

INSERT INTO entries (weight) VALUES (0.), (0.3), (0.1), (0.3), (0.0), (0.2), (0.1);

我们能想到的最好的查询将有一个从rand（）值到特定条目的就绪映射。在这种情况下，我们只需要通过主键找到一个条目。正如我所说，这样一个查询的表将占用一些空间，但是假设我们已经准备好了。我们可能希望将映射保留在内存中，因此可以使用内存引擎，它使用散列索引作为主键（这也很好，因为我们需要将值映射到特定值）。
让我们看看我们的桌子：

mysql> SELECT entry_id, weight FROM entries ORDER BY weight;
+----------+--------+
| entry_id | weight |
+----------+--------+
|        1 |      0 |
|        5 |      0 |
|        3 |    0.1 |
|        7 |    0.1 |
|        6 |    0.2 |
|        2 |    0.3 |
|        4 |    0.3 |
+----------+--------+

让我们创建另一个表并用值填充它：

CREATE table int2entry (
  an_int int(10) unsigned NOT NULL AUTO_INCREMENT,
  entry_id int(10) unsigned NOT NULL,
  PRIMARY KEY (an_int)
) ENGINE=Memory;
TRUNCATE int2entry;
INSERT INTO int2entry (entry_id)
VALUES (3), (7), (6), (6), (2), (2), (2), (4), (4), (4);

其思想是特定条目id的引用数与权重成正比。仅使用SQL可能很难更新该表，并且必须在每次权重更改后对其进行截断和更新，但正如我所说的，在很少更新的情况下，这仍然是一个选项。下面是获取条目id的查询，然后可以将其连接到条目表（您应该知道映射表中的行数）：

SELECT entry_id
FROM (SELECT ceiling(rand() * 10) as an_int) as t1
JOIN int2entry USING (an_int);

另一个解决方案是使用累积权重，并从索引中的顺序中获得优势。
当我们选择数据时，数据是按某种索引顺序选择的（对于主键顺序中的select*）。 weights索引是从权重到条目id的有序映射。如果只选择权重和条目id，则可以直接从 weights索引中获取值，即数据将按索引顺序读取。我们可以使用ORDER BY来强制逆索引顺序进行迭代（较大的权重存储在末尾，但匹配的频率会更高）。为什么重要？因为我们将在WHERE子句中添加一些技巧，并根据处理行的特定顺序进行计算：

SET @rand:= RAND(), @cum_weight:=0.;
SELECT entry_id, weight, @cum_weight, @rand 
FROM entries
WHERE @rand < @cum_weight:=@cum_weight+weight
ORDER BY weight DESC
LIMIT 1;

+----------+--------+----------------------------------+--------------------+
| entry_id | weight | @cum_weight                      | @rand              |
+----------+--------+----------------------------------+--------------------+
|        6 |    0.2 | 0.800000026822090100000000000000 | 0.6957228003961247 |
+----------+--------+----------------------------------+--------------------+

实际上，您只需要输入id，即生成的查询应该如下所示：

SELECT *
FROM entries
JOIN (
  SELECT entry_id
  FROM entries
  JOIN (SELECT @rand:= RAND(), @cum_weight:=0.) as init
  WHERE @rand < @cum_weight:=@cum_weight+weight
  ORDER BY weight DESC
  LIMIT 1) as rand_entry USING (entry_id);

注意 LIMIT 1在找到所需条目时停止处理。
另外，
您可能应该使用十进制类型而不是浮点或双精度来存储权重，以避免在一组较大的较小权重上出现不希望出现的舍入错误。
您可以将有趣的查询隐藏到存储函数中，并使用游标。这个语法似乎更容易理解。