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

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

使用SQL Server 2012+，您可以使用OFFSET FETCH查询对单个随机行执行此操作

select  * from MyTable ORDER BY id OFFSET n ROW FETCH NEXT 1 ROWS ONLY

其中id是一个标识列，n是您想要的行—计算为表的0到count()-1之间的随机数(偏移量0毕竟是第一行)

这适用于表数据中的漏洞，只要您有一个用于ORDER BY子句的索引。它对随机性也很有好处——因为你可以自己计算出来传递进来，但其他方法中的琐碎问题是不存在的。此外，性能非常好，在一个较小的数据集上，它表现得很好，尽管我没有尝试过针对数百万行进行认真的性能测试。

在MSSQL(在11.0.5569上测试)中使用

SELECT TOP 100 * FROM employee ORDER BY CRYPT_GEN_RANDOM(10)

明显快于

SELECT TOP 100 * FROM employee ORDER BY NEWID()

似乎列出的许多想法仍然使用排序

但是，如果使用临时表，则可以分配一个随机索引(就像许多解决方案所建议的那样)，然后获取第一个大于0到1之间任意数字的索引。

例如(对于DB2):

WITH TEMP AS (
SELECT COMLUMN, RAND() AS IDX FROM TABLE)
SELECT COLUMN FROM TABLE WHERE IDX > .5
FETCH FIRST 1 ROW ONLY

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

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

以下方案适用于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条款。在这种情况下，如果第一部分返回任何数据，那么第二部分将永远不会执行!

像Jeremies这样的解决方案:

SELECT * FROM table ORDER BY RAND() LIMIT 1

工作，但是它们需要对所有表进行顺序扫描(因为需要计算与每一行相关联的随机值——这样才能确定最小的值)，即使对于中等大小的表，这也是相当慢的。我的建议是使用某种索引数字列(许多表都将这些列作为主键)，然后编写如下内容:

SELECT * FROM table WHERE num_value >= RAND() * 
    ( SELECT MAX (num_value ) FROM table ) 
ORDER BY num_value LIMIT 1

如果num_value被索引，那么无论表大小如何，它都在对数时间内工作。注意:这里假设num_value在0..MAX(num_value)范围内均匀分布。如果您的数据集严重偏离这个假设，您将得到倾斜的结果(一些行会比其他行出现得更频繁)。