而不是使用RAND()，因为它是不鼓励的，你可以简单地得到max ID (= max):

SELECT MAX(ID) FROM TABLE;

在1..Max (= My_Generated_Random)

My_Generated_Random = rand_in_your_programming_lang_function(1..Max);

然后运行SQL:

SELECT ID FROM TABLE WHERE ID >= My_Generated_Random ORDER BY ID LIMIT 1

注意，它将检查id等于或高于所选值的任何行。 也可以在表中寻找行，并获得一个等于或低于My_Generated_Random的ID，然后修改查询如下:

SELECT ID FROM TABLE WHERE ID <= My_Generated_Random ORDER BY ID DESC LIMIT 1

晚了，但通过谷歌到达这里，所以为了子孙后代，我将添加一个替代解决方案。

另一种方法是使用TOP两次，顺序交替。我不知道它是否是“纯SQL”，因为它在TOP中使用了一个变量，但它在SQL Server 2008中工作。这里有一个例子，如果我想要一个随机的单词，我使用字典单词表。

SELECT TOP 1
  word
FROM (
  SELECT TOP(@idx)
    word 
  FROM
    dbo.DictionaryAbridged WITH(NOLOCK)
  ORDER BY
    word DESC
) AS D
ORDER BY
  word ASC

当然，@idx是目标表上从1到COUNT(*)的随机生成的整数。如果您的列被索引，您也会从中受益。另一个优点是可以在函数中使用它，因为NEWID()是不允许的。

最后，在同一个表上，上述查询的执行时间大约是NEWID()类型查询的1/10。YYMV。

 SELECT * FROM table ORDER BY RAND() LIMIT 1

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

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

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

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

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

明显快于

SELECT TOP 100 * FROM employee ORDER BY NEWID()

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