Det er altid vanskeligt at vælge tilfældige rækker, og der er ingen perfekte løsninger, der ikke involverer et kompromis. Enten kompromittere ydeevnen, eller kompromittere endda tilfældig distribution, eller gå på kompromis med chancen for at vælge dubletter osv.
Som @JakeGould nævner, enhver løsning med ORDER BY RAND() skalerer ikke godt. Efterhånden som antallet af rækker i din tabel bliver større, bliver omkostningerne ved at sortere hele tabellen i en filsortering værre og værre. Jake har ret i, at forespørgslen ikke kan cachelagres, når sorteringsrækkefølgen er tilfældig. Men jeg er ligeglad med det så meget, fordi jeg plejer at deaktivere forespørgselscachen alligevel (den har sine egne skalerbarhedsproblemer).
Her er en løsning til at præ-randomisere rækkerne i tabellen ved at oprette en rækkenumskolonne og tildele unikke på hinanden følgende værdier:
ALTER TABLE products ADD COLUMN rownum INT UNSIGNED, ADD KEY (rownum);
SET @rownum := 0;
UPDATE products SET rownum = (@rownum:[email protected]+1) ORDER BY RAND();
Nu kan du få en tilfældig række ved et indeksopslag, uden sortering:
SELECT * FROM products WHERE rownum = 1;
Eller du kan få den næste tilfældige række:
SELECT * FROM products WHERE rownum = 2;
Eller du kan få 10 tilfældige rækker ad gangen, eller et hvilket som helst andet tal, du ønsker, uden dubletter:
SELECT * FROM products WHERE rownum BETWEEN 11 and 20;
Du kan gen-randomisere, når som helst du vil:
SET @rownum := 0;
UPDATE products SET rownum = (@rownum:[email protected]+1) ORDER BY RAND();
Det er stadig dyrt at udføre den tilfældige sortering, men nu behøver du ikke at gøre det på hver SELECT-forespørgsel. Du kan gøre det efter en tidsplan, forhåbentlig uden for spidsbelastningsperioder.