1
Akitora 2023-03-04 17:32:45 +08:00 via Android
order by rand() limit 10
|
2
falsemask 2023-03-04 18:00:55 +08:00
主键存 redis ,用 redis 的随机函数
|
3
MMMMMMMMMMMMMMMM 2023-03-04 18:23:08 +08:00
线性同余吧,都常数,不占计算资源
https://zh.wikipedia.org/zh-hans/%E7%BA%BF%E6%80%A7%E5%90%8C%E4%BD%99%E6%96%B9%E7%A8%8B SELECT * FROM ( SELECT *, ((@seed := (@seed * 1103515245 + 12345) % (2 ^ 32)) / (2 ^ 32)) AS rand_num FROM table_name, (SELECT @seed := RAND()) AS seed_table ORDER BY rand_num ) AS random_table LIMIT 10; 思路就这样,脏活 gpt 干的,看起来可以跑,自行验证 a b m 可以自己调整,比如想更"随机"点,整个时间戳放进去之类的 |
4
MMMMMMMMMMMMMMMM 2023-03-04 18:29:22 +08:00
哦,傻屌 gpt 果然不能直接信,他还是用了 rand()
SELECT * FROM ( SELECT *, (UNIX_TIMESTAMP() * (@seed := (@seed * UNIX_TIMESTAMP() + 1) % (2 ^ 31 - 1)) / (2 ^ 31 - 1)) AS rand_num FROM table_name, (SELECT @seed := UNIX_TIMESTAMP()) AS seed_table ORDER BY rand_num ) AS random_table LIMIT 10; 这该对了 |
5
auh 2023-03-04 18:44:15 +08:00
数据库里面只放 10 条记录
|
6
makelove 2023-03-04 19:20:10 +08:00
数据量大又要高效的话表加一列随机数列并加索引,可定期重置
|
7
netnr 2023-03-04 19:42:32 +08:00
先 count(*) 总行(可以缓存),程序生成 10+ 的随机 ID (范围在 1- count )
如果自增是主键直接使用主键查询一条,然后 union all 10+ 的查询,这种方式性能应该是最好的 查询 10+ 是考虑删除的情况,最终只返回 10 条 不是自增可以 row_number 加一列序号,在 in ,性能不高 |
8
LeegoYih 2023-03-04 19:52:21 +08:00
id 连续自增,应用服务随机生成 10 个数,用 in(...)查
id 不连续,定时任务查库,随机放一些数据到 rediis ,然后接口从 redis 中随机取 10 条,和热门商品的思路一样 |
9
kenvix 2023-03-04 20:23:01 +08:00
看你的表的情况
ID 是否连续没有中断? 是否可以接受一次随机查询得到的条目少于规定数目? 是否要求高度随机?能否接受一块连续数据? |
10
vace 2023-03-04 21:35:59 +08:00
之前做过百万递增 ID 的用户中随机匹配 N 个,取 maxID ,随机生成 2N 个编号,取出后排除无效用户,一般一次就够了,如果不足,就递归再取一次合并。
|
12
ldyisbest 2023-03-04 22:48:04 +08:00
|
13
ldyisbest 2023-03-04 22:48:37 +08:00
|
14
opengps 2023-03-04 22:52:12 +08:00
先随机 id,再 where id in
|