选择随机行PostgreSQL的最佳方法

Posted

技术标签:

【中文标题】选择随机行PostgreSQL的最佳方法【英文标题】：Best way to select random rows PostgreSQL 【发布时间】：2012-01-30 06:37:50 【问题描述】：

我想在 PostgreSQL 中随机选择行，我试过这个：

select * from table where random() < 0.01;

但其他一些人建议这样做：

select * from table order by random() limit 1000;

我有一个非常大的表，有 5 亿行，我希望它快。

哪种方法更好？有什么区别？选择随机行的最佳方法是什么？

【问题讨论】：

嗨，杰克，感谢您的回复，执行时间按顺序变慢了，但我想知道如果有什么不同的话... 呃……不客气。那么，您是否尝试过对不同方法进行基准测试？ 还有很多更快的方法。这一切都取决于您的要求以及您必须使用的内容。您是否需要正好 1000 行？表是否有数字 ID？没有/很少/很多差距？速度有多重要？每个时间单位有多少请求？每个请求是否需要不同的集合，或者在定义的时间片内它们是否相同？ 第一个选项“(random() 如果只想选择一行，请看这个问题：***.com/q/5297396/247696 【参考方案1】：

postgresql order by random()，随机选择行：

这很慢，因为它对整个表进行排序以保证每一行都有完全相等的被选中机会。为了完美的随机性，全表扫描是不可避免的。

select your_columns from your_table ORDER BY random()

postgresql order by random() with a distinct：

select * from 
  (select distinct your_columns from your_table) table_alias
ORDER BY random()

postgresql order by 随机限制一行：

这也很慢，因为它必须进行表扫描以确保可能被选中的每一行都有相同的机会被选中，就在这一刻：

select your_columns from your_table ORDER BY random() limit 1

Constant Time Select Random N 行与周期表扫描：

如果您的表很大，那么上面的表扫描是一个显示停止器，最多需要 5 分钟才能完成。

为了更快，您可以在后台安排每晚的表扫描重新索引，这将保证以O(1) 恒定时间速度进行完全随机选择，除非在每晚重新索引表扫描期间，它必须等待维护在您收到另一个随机行之前完成。

--Create a demo table with lots of random nonuniform data, big_data 
--is your huge table you want to get random rows from in constant time. 
drop table if exists big_data;  
CREATE TABLE big_data (id serial unique, some_data text );  
CREATE INDEX ON big_data (id);  
--Fill it with a million rows which simulates your beautiful data:  
INSERT INTO big_data (some_data) SELECT md5(random()::text) AS some_data
FROM generate_series(1,10000000);
 
--This delete statement puts holes in your index
--making it NONuniformly distributed  
DELETE FROM big_data WHERE id IN (2, 4, 6, 7, 8); 
 
 
--Do the nightly maintenance task on a schedule at 1AM.
drop table if exists big_data_mapper; 
CREATE TABLE big_data_mapper (id serial, big_data_id int); 
CREATE INDEX ON big_data_mapper (id); 
CREATE INDEX ON big_data_mapper (big_data_id); 
INSERT INTO big_data_mapper(big_data_id) SELECT id FROM big_data ORDER BY id;
 
--We have to use a function because the big_data_mapper might be out-of-date
--in between nightly tasks, so to solve the problem of a missing row, 
--you try again until you succeed.  In the event the big_data_mapper 
--is broken, it tries 25 times then gives up and returns -1. 
CREATE or replace FUNCTION get_random_big_data_id()  
RETURNS int language plpgsql AS $$ 
declare  
    response int; 
BEGIN
    --Loop is required because big_data_mapper could be old
    --Keep rolling the dice until you find one that hits.
    for counter in 1..25 loop
        SELECT big_data_id 
        FROM big_data_mapper OFFSET floor(random() * ( 
            select max(id) biggest_value from big_data_mapper 
            )
        ) LIMIT 1 into response;
        if response is not null then
            return response;
        end if;
    end loop;
    return -1;
END;  
$$; 
 
--get a random big_data id in constant time: 
select get_random_big_data_id(); 
 
--Get 1 random row from big_data table in constant time: 
select * from big_data where id in ( 
    select get_random_big_data_id() from big_data limit 1 
); 
┌─────────┬──────────────────────────────────┐ 
│   id    │            some_data             │ 
├─────────┼──────────────────────────────────┤ 
│ 8732674 │ f8d75be30eff0a973923c413eaf57ac0 │ 
└─────────┴──────────────────────────────────┘ 

--Get 4 random rows from big_data in constant time: 
select * from big_data where id in ( 
    select get_random_big_data_id() from big_data limit 3 
);
┌─────────┬──────────────────────────────────┐ 
│   id    │            some_data             │ 
├─────────┼──────────────────────────────────┤ 
│ 2722848 │ fab6a7d76d9637af89b155f2e614fc96 │ 
│ 8732674 │ f8d75be30eff0a973923c413eaf57ac0 │ 
│ 9475611 │ 36ac3eeb6b3e171cacd475e7f9dade56 │ 
└─────────┴──────────────────────────────────┘ 

--Test what happens when big_data_mapper stops receiving 
--nightly reindexing.
delete from big_data_mapper where 1=1; 
select get_random_big_data_id();   --It tries 25 times, and returns -1
                                   --which means wait N minutes and try again.

改编自：https://www.gab.lc/articles/bigdata_postgresql_order_by_random

或者，您可以摆脱映射器表并将其设置为 big_data 上的 1 个新列。然后您只需在函数/过程中“在0 ... max(id) 之间选择一个随机整数”（两者都是恒定时间操作），然后返回该索引，如果它不再存在，因为没有重新索引最近完成，请选择另一个。

【讨论】：

select your_columns from your_table ORDER BY random() limit 1 执行 4500 万行需要大约 2 分钟 有没有办法加快速度？【参考方案2】：

鉴于您的规格（以及 cmets 中的其他信息），

您有一个数字 ID 列（整数），只有很少（或很少）间隙。 显然没有或很少写操作。 您的 ID 列必须被索引！主键很好用。

下面的查询不需要大表的顺序扫描，只需要索引扫描。

首先，获取主查询的估计值：

SELECT count(*) AS ct              -- optional
     , min(id)  AS min_id
     , max(id)  AS max_id
     , max(id) - min(id) AS id_span
FROM   big;

唯一可能昂贵的部分是count(*)（用于大桌子）。鉴于上述规格，您不需要它。估计就可以了，几乎免费提供 (detailed explanation here)：

SELECT reltuples AS ct FROM pg_class
WHERE oid = 'schema_name.big'::regclass;

只要ct 不比id_span 小很多，查询的性能就会优于其他方法。

WITH params AS (
   SELECT 1       AS min_id           -- minimum id <= current min id
        , 5100000 AS id_span          -- rounded up. (max_id - min_id + buffer)
    )
SELECT *
FROM  (
   SELECT p.min_id + trunc(random() * p.id_span)::integer AS id
   FROM   params p
         ,generate_series(1, 1100) g  -- 1000 + buffer
   GROUP  BY 1                        -- trim duplicates
) r
JOIN   big USING (id)
LIMIT  1000;                          -- trim surplus

在id 空间中生成随机数。您有“很少的空白”，因此将 10 %（足以轻松覆盖空白）添加到要检索的行数。

每个id 都可以偶然被选中多次（尽管在 id 空间很大的情况下不太可能），因此对生成的数字进行分组（或使用 DISTINCT）。

加入ids 到大桌子。有了索引，这应该非常快。

最后修剪没有被骗子和差距吃掉的多余ids。每一行都有完全平等的机会被选中。

短版

您可以简化此查询。上述查询中的 CTE 仅用于教育目的：

SELECT *
FROM  (
   SELECT DISTINCT 1 + trunc(random() * 5100000)::integer AS id
   FROM   generate_series(1, 1100) g
   ) r
JOIN   big USING (id)
LIMIT  1000;

用 rCTE 优化

特别是如果您对差距和估计不太确定。

WITH RECURSIVE random_pick AS (
   SELECT *
   FROM  (
      SELECT 1 + trunc(random() * 5100000)::int AS id
      FROM   generate_series(1, 1030)  -- 1000 + few percent - adapt to your needs
      LIMIT  1030                      -- hint for query planner
      ) r
   JOIN   big b USING (id)             -- eliminate miss

   UNION                               -- eliminate dupe
   SELECT b.*
   FROM  (
      SELECT 1 + trunc(random() * 5100000)::int AS id
      FROM   random_pick r             -- plus 3 percent - adapt to your needs
      LIMIT  999                       -- less than 1000, hint for query planner
      ) r
   JOIN   big b USING (id)             -- eliminate miss
   )
TABLE  random_pick
LIMIT  1000;  -- actual limit

我们可以在基本查询中使用较小的剩余。如果有太多间隙，我们在第一次迭代中找不到足够的行，则 rCTE 继续使用递归项进行迭代。我们在 ID 空间中仍然需要相对 很少 个间隙，否则递归可能会在达到限制之前耗尽 - 或者我们必须从一个足够大的缓冲区开始，这违背了优化性能的目的。

rCTE 中的UNION 消除了重复项。

一旦我们有足够的行，外部的LIMIT 就会停止 CTE。

此查询经过精心起草，以使用可用索引，生成实际上是随机的行，并且在我们达到限制之前不会停止（除非递归运行枯竭）。如果你要重写它，这里有很多陷阱。

包装成函数

对于不同参数的重复使用：

CREATE OR REPLACE FUNCTION f_random_sample(_limit int = 1000, _gaps real = 1.03)
  RETURNS SETOF big
  LANGUAGE plpgsql VOLATILE ROWS 1000 AS
$func$
DECLARE
   _surplus  int := _limit * _gaps;
   _estimate int := (           -- get current estimate from system
      SELECT c.reltuples * _gaps
      FROM   pg_class c
      WHERE  c.oid = 'big'::regclass);
BEGIN
   RETURN QUERY
   WITH RECURSIVE random_pick AS (
      SELECT *
      FROM  (
         SELECT 1 + trunc(random() * _estimate)::int
         FROM   generate_series(1, _surplus) g
         LIMIT  _surplus           -- hint for query planner
         ) r (id)
      JOIN   big USING (id)        -- eliminate misses

      UNION                        -- eliminate dupes
      SELECT *
      FROM  (
         SELECT 1 + trunc(random() * _estimate)::int
         FROM   random_pick        -- just to make it recursive
         LIMIT  _limit             -- hint for query planner
         ) r (id)
      JOIN   big USING (id)        -- eliminate misses
   )
   TABLE  random_pick
   LIMIT  _limit;
END
$func$;

呼叫：

SELECT * FROM f_random_sample();
SELECT * FROM f_random_sample(500, 1.05);

您甚至可以使这个泛型适用于任何表：将 PK 列的名称和表作为多态类型并使用 EXECUTE ...但这超出了本问题的范围。见：

Refactor a PL/pgSQL function to return the output of various SELECT queries

可能的替代方案

如果您的要求允许重复调用的相同集（我们正在谈论重复调用），我会考虑物化视图。执行一次上述查询并将结果写入表。用户以闪电般的速度获得准随机选择。每隔一段时间或您选择的事件刷新您的随机选择。

Postgres 9.5 引入TABLESAMPLE SYSTEM (n)

n 是一个百分比。 The manual:

BERNOULLI 和 SYSTEM 采样方法均接受单个 参数是要采样的表的分数，表示为 0 到 100 之间的百分比。这个参数可以是任何real-valued 表达式。

我的大胆强调。它非常快，但结果并非完全随机。再看手册：

SYSTEM 方法明显快于BERNOULLI 方法 当指定小采样百分比时，它可能会返回一个 由于聚类效应，表的随机样本较少。

返回的行数可以变化很大。对于我们的示例，要获得大约 1000 行：

SELECT * FROM big TABLESAMPLE SYSTEM ((1000 * 100) / 5100000.0);

相关：

Fast way to discover the row count of a table in PostgreSQL

或安装附加模块 tsm_system_rows 以准确获取请求的行数（如果足够的话）并允许更方便的语法：

SELECT * FROM big TABLESAMPLE SYSTEM_ROWS(1000);

详情请见Evan's answer。

但这仍然不是完全随机的。

【讨论】：

t 表在哪里定义？它应该 r 而不是 t 吗？ @LucM：这里定义为：JOIN bigtbl t，是JOIN bigtbl AS t的缩写。 t 是 table alias 的 bigtbl。它的目的是缩短语法，但在这种特殊情况下不需要它。我在回答中简化了查询并添加了一个简单的版本。 generate_series(1,1100) 的值范围的用途是什么？ @Awesome-o：目标是检索 1000 行，我从额外的 10% 开始以补偿一些空白或（不太可能但可能）重复的随机数......解释在我的回答。 Erwin，我发布了您的“可能替代方案”的变体：***.com/a/23634212/430128。会对您的想法感兴趣。【参考方案3】：

带有 ORDER BY 的那个将是较慢的那个。

select * from table where random() &lt; 0.01; 逐条记录，并决定是否随机过滤。这将是O(N)，因为它只需要检查每条记录一次。

select * from table order by random() limit 1000; 将对整个表进行排序，然后选择前 1000 个。除了幕后的任何巫术魔法之外，顺序是 O(N * log N)。

random() &lt; 0.01 的缺点是您将获得可变数量的输出记录。

注意，有一种比随机排序更好的方法来打乱一组数据：The Fisher-Yates Shuffle，它在O(N) 中运行。不过，在 SQL 中实现 shuffle 听起来颇具挑战。

【讨论】：

尽管如此，您没有理由不能在第一个示例的末尾添加限制 1。唯一的问题是您可能无法取回任何记录，因此您必须在代码中考虑到这一点。 Fisher-Yates 的问题在于您需要将整个数据集保存在内存中才能从中进行选择。对于非常大的数据集不可行:(【参考方案4】：

从 PostgreSQL 9.5 开始，有一种专门用于从表中获取随机元素的新语法：

SELECT * FROM mytable TABLESAMPLE SYSTEM (5);

这个例子会给你来自mytable的5%的元素。

查看文档的更多解释：http://www.postgresql.org/docs/current/static/sql-select.html

【讨论】：

文档中的重要说明：“SYSTEM 方法对每个块进行块级采样，每个块具有指定的被选中机会；返回每个选定块中的所有行。SYSTEM 方法明显更快比 BERNOULLI 方法指定小的抽样百分比时，但它可能会返回一个较少随机的表样本作为结果的聚类效应。" 有没有办法指定行数而不是百分比？ 您可以使用 TABLESAMPLE SYSTEM_ROWS(400) 获取 400 个随机行的样本。您需要启用built-in tsm_system_rows extension 才能使用此语句。【参考方案5】：

我的经验教训：

offset floor(random() * N) limit 1 并不比order by random() limit 1 快。

我认为offset 方法会更快，因为它可以节省在 Postgres 中排序的时间。原来不是。

【讨论】：

【参考方案6】：

我知道我参加聚会有点晚了，但我刚刚发现了这个很棒的工具，叫做pg_sample：

pg_sample - 从较大的 PostgreSQL 数据库中提取一个小的样本数据集，同时保持引用完整性。

我用一个 350M 行的数据库试过这个，速度真的很快，不知道 随机性。

./pg_sample --limit="small_table = *" --limit="large_table = 100000" -U postgres source_db | psql -U postgres target_db

【讨论】：

【参考方案7】：

这是一个适合我的决定。我想这很容易理解和执行。

SELECT 
  field_1, 
  field_2, 
  field_2, 
  random() as ordering
FROM 
  big_table
WHERE 
  some_conditions
ORDER BY
  ordering 
LIMIT 1000;

【讨论】：

我认为这个解决方案就像ORDER BY random() 一样有效，但在处理大表时可能效率不高。【参考方案8】： 
select * from table order by random() limit 1000;

如果您知道需要多少行，请查看tsm_system_rows。

tsm_system_rows

模块提供了表采样方法SYSTEM_ROWS，可以在SELECT命令的TABLESAMPLE子句中使用。

此表采样方法接受一个整数参数，该参数是要读取的最大行数。生成的样本将始终包含那么多行，除非表不包含足够的行，在这种情况下会选择整个表。 与内置的 SYSTEM 采样方法一样，SYSTEM_ROWS 执行块级采样，因此样本不是完全随机的，而是可能会受到聚类效应的影响，尤其是在仅请求少量行的情况下。

首先安装扩展

CREATE EXTENSION tsm_system_rows;

然后是你的查询，

SELECT *
FROM table
TABLESAMPLE SYSTEM_ROWS(1000);

【讨论】：

我添加了指向您添加的答案的链接，这是对内置 SYSTEM 方法的显着改进。 我刚刚回答了一个问题here（随机单条记录），在此期间我执行了相当多的benchmarking and testing tsm_system_rows 和tsm_system_time 扩展。据我所知，除了绝对minimal 选择随机行之外，它们几乎无用。如果您能快速查看并评论我的分析的有效性或其他方面，我将不胜感激。【参考方案9】：

添加名为r 的列，类型为serial。索引r。

假设我们有 200,000 行，我们将生成一个随机数 n，其中 0 n

选择带有r &gt; n 的行，对它们进行排序ASC 并选择最小的行。

代码：

select * from YOUR_TABLE 
where r > (
    select (
        select reltuples::bigint AS estimate
        from   pg_class
        where  oid = 'public.YOUR_TABLE'::regclass) * random()
    )
order by r asc limit(1);

代码是不言自明的。中间的子查询用于从https://***.com/a/7945274/1271094快速估计表行数。

在应用程序级别如果n>行数或需要选择多行，则需要再次执行该语句。

【讨论】：

我喜欢这个，因为它简短而优雅 :) 我什至找到了改进它的方法：EXPLAIN ANALYZE 告诉我，像这样，不会使用 PKEY 索引，因为 random() 返回一个 double ，而 PKEY 需要一个 BIGINT。 select * from YOUR_TABLE where r > ( select (select reltuples::bigint AS 估计来自 pg_class where oid = 'public.YOUR_TABLE'::regclass) * random() )::BIGINT order by r asc 限制（1）；【参考方案10】：

如果您只想要一行，您可以使用从count 派生的计算offset。

select * from table_name limit 1
offset floor(random() * (select count(*) from table_name));

【讨论】：

【参考方案11】：

物化视图“可能的替代方案”outlined by Erwin Brandstetter 的变体是可能的。

例如，假设您不希望返回的随机值中有重复项。因此，您需要在包含您的（非随机）值集的主表上设置一个布尔值。

假设这是输入表：

id_values  id  |   used
           ----+--------
           1   |   FALSE
           2   |   FALSE
           3   |   FALSE
           4   |   FALSE
           5   |   FALSE
           ...

根据需要填充ID_VALUES 表。然后，如 Erwin 所述，创建一个物化视图，将 ID_VALUES 表随机化一次：

CREATE MATERIALIZED VIEW id_values_randomized AS
  SELECT id
  FROM id_values
  ORDER BY random();

请注意，物化视图不包含已使用的列，因为它很快就会过时。视图也不需要包含可能在id_values 表中的其他列。

为了获得（和“使用”）随机值，请在id_values 上使用UPDATE-RETURNING，从id_values_randomized 中选择id_values 并进行连接，并应用所需的标准以仅获得相关的可能性。例如：

UPDATE id_values
SET used = TRUE
WHERE id_values.id IN 
  (SELECT i.id
    FROM id_values_randomized r INNER JOIN id_values i ON i.id = r.id
    WHERE (NOT i.used)
    LIMIT 5)
RETURNING id;

根据需要更改LIMIT -- 如果您一次只需要一个随机值，请将LIMIT 更改为1。

通过id_values 上的正确索引，我相信 UPDATE-RETURNING 应该会在很少负载的情况下非常快速地执行。它通过一次数据库往返返回随机值。 “合格”行的标准可以根据需要复杂。可以随时将新行添加到id_values 表中，一旦物化视图刷新（可能在非高峰时间运行），应用程序就可以访问它们。物化视图的创建和刷新会很慢，但只需要在id_values 表中添加新的 id 时执行。

【讨论】：

非常有趣。如果我不仅需要选择而且还需要使用 select..for 使用 pg_try_advisory_xact_lock 进行更新，那会起作用吗？ （即我需要许多并发读写）【参考方案12】：

您可以使用

检查和比较两者的执行计划 
EXPLAIN select * from table where random() < 0.01;
EXPLAIN select * from table order by random() limit 1000;

对大表的快速测试1 显示，ORDER BY 首先对整个表进行排序，然后选择前 1000 个项目。对大表进行排序不仅会读取该表，还涉及读取和写入临时文件。 where random() &lt; 0.1 只扫描整个表一次。

对于大型表，这可能不是您想要的，因为即使是一次完整的表扫描也可能需要很长时间。

第三个建议是

select * from table where random() < 0.01 limit 1000;

一旦找到 1000 行，此操作就会停止表扫描，因此会更快返回。当然，这会稍微降低随机性，但在你的情况下这可能已经足够了。

编辑：除了这些考虑之外，您还可以查看已经提出的问题。使用查询 [postgresql] random 会返回很多命中。

quick random row selection in Postgres How to retrieve randomized data rows from a postgreSQL table? postgres: get random entries from table - too slow

还有 depez 的链接文章概述了更多方法：

http://www.depesz.com/index.php/2007/09/16/my-thoughts-on-getting-random-row/

1 “大”，如“整个表无法放入内存”。

【讨论】：

关于编写用于订购的临时文件的要点。这确实是一个很大的打击。我想我们可以做random() &lt; 0.02，然后洗牌该列表，然后limit 1000！几千行的排序会更便宜（大声笑）。 "select * from table where random() 为什么您会考虑使用 O(n) 完全扫描来检索 500m 行表上的样本？在大桌子上速度慢得离谱，完全没有必要。

以上是关于选择随机行PostgreSQL的最佳方法的主要内容，如果未能解决你的问题，请参考以下文章

从具有加权行概率的 PostgreSQL 表中选择随机行

在PostgreSQL中选择N个匹配条件的随机行

通过 SQLAlchemy 获取随机行

如何从没有数字主键的表中有效地选择随机行

PostgreSQL 中的快速随机行：为啥 time (floor(random()*N)) + (select * from a where id = const) 比 select where i

从大表的子集中对随机行进行最快查询 - postgresql