mysql随机排序

2020-02-13 13:37:53

参考地址 mysql随机排序

需求:首页热门栏目需要随机显示几条信息


方案1:order by rand(),全表扫描


SELECT SQL_NO_CACHE * FROM `house_rent` order by rand() limit 10

(共 1 行, 查询花费 0.1069秒)

explain SELECT * FROM `house_rent` order by rand() limit 1

id   select_type       table          type       possible_keys   key      key_len        ref         rows                           Extra

1       SIMPLE     house_rent    ALL                NULL       NULL       NULL      NULL      1009   Using temporary; Using filesort


方案2:拆分两个sql语句,第一个先随机取得id,可以用到index索引,第二个根据这些id直接定位。总用时0.0021,单需要两次请求


SELECT SQL_NO_CACHE id FROM `house_rent` order by rand() limit 10 

(共 1 行, 查询花费 0.0012 秒)

explain SELECT id FROM `house_rent` order by rand() limit 10 

id   select_type       table          type       possible_keys   key      key_len        ref         rows                           Extra 

1       SIMPLE     house_rent    index             NULL             uid             5             NULL     1690    Using index; Using temporary; Using filesort


SELECT SQL_NO_CACHE * FROM `house_rent` where id in (298,106,533,545,2,446,1367,1509,759,499)

(共 10 行, 查询花费 0.0009 秒)


方案3:将方案2两次请求用子查询合并为一次,查询时间比方案2高5倍,可见效果并不好,为了满足mysql语法生成了2张临时表。但是这种子查询并没有引发了笛卡尔积


SELECT SQL_NO_CACHE * FROM `house_rent` where id in ( select id from (SELECT id FROM `house_rent` order by rand() limit 10 ) as a )

(共 10 行, 查询花费 0.0110 秒)

SELECT SQL_NO_CACHE * FROM `house_rent` where id in ( select id from (SELECT id FROM `house_rent` order by rand() limit 50 ) as a )

(共 50 行, 查询花费 0.0071 秒)


方案4:利用子查询先计算一个随机点,然后再取小于该随机点的n条数据,因为取值是连贯的,所以速度比较快。而且子查询语句是纯数学计算,也不会有临时表影响。此方案虽然结果是连续的几个值,但每次获取的内容不一样,可以满足需求


select SQL_NO_CACHE * from house_rent where status=1 and cid=4 and (select ceil(rand()*(select MAX( id ) from house_rent)))<=id limit 10

(共 10 行, 查询花费 0.0011 秒)




explain select SQL_NO_CACHE * from house_rent where status=1 and cid=4 and (select ceil(rand()*(select MAX( id ) from house_rent)))<=id limit 10

id   select_type       table                 type       possible_keys   key      key_len        ref         rows                           Extra 

1      PRIMARY       house_rent       ref            status             status          2             const     1478                Using where

3     SUBQUERY        NULL          NULL         NULL                NULL       NULL       NULL     NULL     Select tables optimized away


  • 2019-05-28 13:33:20

    BRVAH+MTRVA,复杂?不存在的

    言归正传,这样的一个首页,我们需要做怎么样的基础工作呢?或者说,碰到以后更复杂的页面我们应该怎么做?这里小提示下,不要再用什么类似ScrollView的这种东西了,诶,好像说的有点绝对,尽量不要用,这不是谷歌想要看到的,5.0谷歌推出了RecyclerView,从它的整个设计架构来看,简直就是为这而生的。而RecyclerView的视图是通过Adapter来渲染的。原始的Adapter,让人很蛋疼,重复工作太多,我们应该要有封装的思想,把最需要的部分提供出来,其它不用管。

  • 2019-05-29 14:19:19

    解决Git中fatal: refusing to merge unrelated histories

    Git的报错 在使用Git的过程中有时会出现一些问题,那么在解决了每个问题的时候,都需要去总结记录下来,下次不再犯。 一、fatal: refusing to merge unrelated histories 今天在使用Git创建项目的时候,在两个分支合并的时候,出现了下面的这个错误。

  • 2019-05-29 15:47:51

    撤销commit

    在git push的时候,有时候我们会想办法撤销git commit的内容

  • 2019-06-03 00:07:32

    Android程序Crash时的异常上报

    家都知道,android应用不可避免的会发生crash,无论你的程序写的多完美,总是无法完全避免crash的发生,可能是由于android系统底层的bug,也可能是由于不充分的机型适配或者是糟糕的网络状况。当crash发生时,系统会kill掉你的程序,表现就是闪退或者程序已停止运行,这对用户来说是很不友好的,也是开发者所不愿意看到的,更糟糕的是,当用户发生了crash,开发者却无法得知程序为何crash,即便你想去解决这个crash,但是由于你无法知道用户当时的crash信息,所以你也无能为力。是否真的这样呢,其实android中有处理这类问题的方法,请看下面Thread类中的一个方法#setDefaultUncaughtExceptionHandler