MySQL 随机函数获取数据速度和效率分析

在mysql中带了随机取数据的函数，在mysql中我们会有rand()函数，很多朋友都会直接使用，如果几百条数据肯定没事，如果几万或百万时你会发现，直接使用是错误的。下面我来介绍随机取数据一些优化方法。

SELECT

*

FROM

table_name

ORDER

BY

rand()

LIMIT

5

rand在手册里是这么说的:

RAND()

RAND(N)

返回在范围0到1.0内的随机浮点值。如果一个整数参数N被指定，它被用作种子值。

mysql>

select

RAND()

->

0.5925

mysql>

select

RAND(20)

->

0.1811

mysql>

select

RAND(20)

->

0.1811

mysql>

select

RAND()

->

0.2079

mysql>

select

RAND()

->

0.7888

你不能在一个ORDER

BY子句用RAND()值使用列，因为ORDER

BY将重复计算列多次。然而在MySQL3.23中，你可以做：

SELECT

*

FROM

table_name

ORDER

BY

RAND()，这是有利于得到一个来自SELECT

*

FROM

table1,table2

WHERE

a=b

AND

c<d

ORDER

BY

RAND()

LIMIT

1000的集合的随机样本。注意在一个WHERE子句里的一个RAND()将在每次WHERE被执行时重新评估。

网上基本上都是查询max(id)

*

rand()来随机获取数据。

SELECT

*

FROM

`table`

AS

t1

JOIN

(SELECT

ROUND(RAND()

*

(SELECT

MAX(id)

FROM

`table`))

AS

id)

AS

t2

WHERE

t1.id

>=

t2.id

ORDER

BY

t1.id

ASC

LIMIT

5

但是这样会产生连续的5条记录。解决办法只能是每次查询一条，查询5次。即便如此也值得，因为15万条的表，查询只需要0.01秒不到。

上面的语句采用的是JOIN，mysql的论坛上有人使用

SELECT

*

FROM

`table`

WHERE

id

>=

(SELECT

FLOOR(

MAX(id)

*

RAND())

FROM

`table`

)

ORDER

BY

id

LIMIT

1

我测试了一下，需要0.5秒，速度也不错，但是跟上面的语句还是有很大差距

后来请教了baidu,得到如下代码

完整查询语句是：

SELECT

*

FROM

`table`

WHERE

id

>=

(SELECT

floor(

RAND()

*

((SELECT

MAX(id)

FROM

`table`)-(SELECT

MIN(id)

FROM

`table`))

+

(SELECT

MIN(id)

FROM

`table`)))

ORDER

BY

id

LIMIT

1

SELECT

*

FROM

`table`

AS

t1

JOIN

(SELECT

ROUND(RAND()

*

((SELECT

MAX(id)

FROM

`table`)-(SELECT

MIN(id)

FROM

`table`))+(SELECT

MIN(id)

FROM

`table`))

AS

id)

AS

t2

WHERE

t1.id

>=

t2.id

ORDER

BY

t1.id

LIMIT

1

最后在php中对这两个语句进行分别查询10次，

前者花费时间

0.147433

秒

后者花费时间

0.015130

秒

执行效率需要0.02

sec.可惜的是,只有mysql

4.1.*以上才支持这样的子查询.

注意事项

查看官方手册，也说rand()放在ORDER

BY

子句中会被执行多次，自然效率及很低。

以上的sql语句最后一条，本人实际测试通过，100W数据，瞬间出结果。

感谢阅读，希望能帮助到大家，谢谢大家对本站的支持！

MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。

如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。

临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。

---