ORDER BY NEWID()

耗时7.4毫秒

WHERE num_value >= RAND() * (SELECT MAX(num_value) FROM table)

只需要0.0065毫秒!

我肯定会选择后一种方法。

这里的大多数解决方案都旨在避免排序，但它们仍然需要对表进行顺序扫描。

还有一种方法可以通过切换到索引扫描来避免顺序扫描。如果你知道你随机行的下标值，你几乎可以立即得到结果。问题是——如何猜测一个索引值。

以下方案适用于PostgreSQL 8.4版本:

explain analyze select * from cms_refs where rec_id in 
  (select (random()*(select last_value from cms_refs_rec_id_seq))::bigint 
   from generate_series(1,10))
  limit 1;

我上面的解决方案你猜10个不同的随机指标值从范围0 ..[id的最后一个值]。

数字10是任意的-你可以使用100或1000，因为它(令人惊讶的是)对响应时间没有太大的影响。

还有一个问题-如果你有稀疏的id，你可能会错过。解决方案是有一个备份计划:)在这种情况下，一个纯旧order by random()查询。当合并id看起来像这样:

explain analyze select * from cms_refs where rec_id in 
    (select (random()*(select last_value from cms_refs_rec_id_seq))::bigint 
     from generate_series(1,10))
    union all (select * from cms_refs order by random() limit 1)
    limit 1;

不是union ALL条款。在这种情况下，如果第一部分返回任何数据，那么第二部分将永远不会执行!

我不得不同意CD-MaN:使用“ORDER BY RAND()”将很好地用于小表或当你只做几次SELECT时。

我还使用“num_value >= RAND() *…”技术，如果我真的想获得随机结果，我在表中有一个特殊的“随机”列，我大约每天更新一次。单个UPDATE运行将花费一些时间(特别是因为必须在该列上建立索引)，但它比每次运行select时为每一行创建随机数快得多。

我不知道这有多有效，但我以前用过:

SELECT TOP 1 * FROM MyTable ORDER BY newid()

因为guid是非常随机的，所以顺序意味着您得到的是随机行。

要小心，因为TableSample实际上并不返回随机的行样本。它引导您的查询查看组成行的8KB页面的随机样本。然后，对这些页面中包含的数据执行查询。由于数据在这些页面上的分组方式(插入顺序等)，这可能导致数据实际上不是随机样本。

参见:http://www.mssqltips.com/tip.asp?tip=1308

该表的MSDN页面包含了如何生成实际随机数据样本的示例。

http://msdn.microsoft.com/en-us/library/ms189108.aspx

正如@BillKarwin对@cnu回答的评论所指出的那样…

当与LIMIT结合使用时，我发现随机排序的JOIN比直接对实际行进行排序执行得更好(至少在PostgreSQL 9.1中)。 SELECT * FROM tbl_post AS t 加入…… JOIN (SELECT id, CAST(-2147483648 * RANDOM() AS integer) AS rand 从tbl_post WHERE create_time >= 1349928000 ) r ON r.id = t.d id WHERE create_time >= 1349928000 AND… ORDER BY r.r rand 限制100

只要确保“r”为与它连接的复杂查询中的每个可能的键值生成一个“rand”值，但仍然尽可能限制“r”的行数。

CAST as Integer对于PostgreSQL 9.2特别有用，它对整型和单精度浮点类型有特定的排序优化。