Dotaz: MySQL ORDER BY RAND() a výkon

[filbar]

V jednom modulu webové aplikace jsem se setkal s

ORDER BY RAND()
LIMIT 1

jak je na tom takový dotaz s výkonností? Tuším správně, že je to pro výkonnost špatné?

Odpovědi

[MMMMMMMMM]

Je to čiré zlo. :) https://www.google.cz/search?q=order+by+rand+mysql+alternative

[kuka]

To predevsim zalezi, ceho se to tyka. Jestli to pracuje treba nad 100 zaznamy, tak na tom urcite nic spatneho neni. Podobne pokud to jednou mesicne vylosuje jednoho uzivatele, nebude vadit, ze to pobezi nekolik minut, naopak pokud se to vola stokrat za minutu, musi to bezet radove desetiny sekundy atd.

[Šangala]

To je ale kravina, znám lepší způsoby jak zatížit server.
Velmi výkonné je to na M$SQL, ale zas to nedělá to, co by se očekávalo .

[AraxoN]

jj, MS SQL vygeneruje rovnaké náhodné číslo pre všetky riadky. To je prosímpekne vlastnosť, nie chyba!

[Josef Kufner]

Potíž je v tom, že MySQL si napřed vygeneruje ke každému řádku náhodné číslo, pak řádky podle tohoto čísla seřadí a nakonec veme ten první. Takže si potřebuje udělat dočasnou tabulku, která pojme všechny řádky ve zdrojové tabulce (tedy alespoň ta náhodná čísla), tu pak seřadit a nakonec zahodit, protože je potřeba jen jeden řádek.

Pokud chceš jen jeden náhodný řádek, dej RAND() * (SELECT COUNT(*)) do offsetu v LIMIT.

Pokud chceš řádků více, je to trochu těžší. Pro několik málo řádků prostě volej jednořádkovou variantu kolikrát potřebuješ. Pro hodně řádků, pokud máš jako primární klíč celá čísla, můžeš vygenerovat seznam náhodných ID a pak si o ně říct. Pokud jsou ID děravá, tak to spustíš vícekrát, dokud nedostaneš požadovaný počet (můžeš ID vygenerovat pár navíc aby jsi omezil počet dotazů).

[AraxoN]

Možno to platí len pre postgresql, ale výhodnejšie je ORDER BY RANDOM(), než OFFSET RANDOM() * SELECT COUNT():

EXPLAIN SELECT * FROM test ORDER BY RANDOM() LIMIT 1;
                                     QUERY PLAN
-------------------------------------------------------------------------------------
 Limit  (cost=19755.35..19755.36 rows=1 width=1162)
   ->  Sort  (cost=19755.35..20165.12 rows=163906 width=1162)
         Sort Key: (random())
         ->  Seq Scan on test  (cost=0.00..18935.83 rows=163906 width=1162)
(4 rows)

EXPLAIN SELECT * FROM test LIMIT 1 OFFSET RANDOM()*(SELECT COUNT(*) FROM test);
                                     QUERY PLAN
------------------------------------------------------------------------------------
 Limit  (cost=20788.49..20788.60 rows=1 width=1162)
   InitPlan 1 (returns $0)
     ->  Aggregate  (cost=18935.83..18935.84 rows=1 width=0)
           ->  Seq Scan on test  (cost=0.00..18526.06 rows=163906 width=0)
   ->  Seq Scan on test  (cost=0.00..18526.06 rows=163906 width=1162)
(5 rows)

Cost prvej možnosti je nižší než druhej.

[Šangala]

Záleží na tom jak moc je efektivní 'COUNT(*)' a nad jak velkými daty se to dělá.
U mě na MySQL (InnoDB i MyISAM) nad tabulkou s několika záznamy je ekvivalent druhého zápisu také rychlejší, ale s např. 180000 záznamy už ne (použil jsem co jsem měl po ruce - proto to číslo), ale celé je to o tom, že nejdéle trvá 'SELECT COUNT(*)…', pokud tedy budu losovat několik záznamů tak už je to diametrálně jiné, samozřejmě se ale nesmí použít ten uvedený druhý zápis, ale uložení si COUNT(*).
Čísla na 180 000 záznamech:

InnoDB: 0.21sec (získání COUNT(*) z toho 0.16 sec)   vs.   0.29sec 
MyISAM: 0.08sec (získání COUNT(*) z toho 0.05 sec)   vs.   0.18sec

[Heron]

U MVCC databáze (tedy asi všechno krom MyISAM) je COUNT(*) velmi drahá operace. Musí se spočítat řádky platné v dané transakci.

[okbob]

cost je hausnumero, to ještě nic nemusí znamenat - v každém případku použití ORDER BY RANDOM vede na sekvenční scan, což u velkých tabulek může být brzda - a tuplem, když je takový dotaz častý - pro tabulky do několikaseti řádků je to jedno, ale pak už to může zabolet. Viděl jsem server, kde významnou část zátěže produkoval podobný a pro většinu aplikací naprosto zbytný dotaz.

[Heron]

Ale v každém případě se provádí sekvenční scan celé tabulky a v tom druhém případě dokonce dvakrát. Pro normálně velké tabulky ten server tímto efektivně odstavíte.

[l0gik]

U nepříliš děravé databáze, která neumí count bez prolejzání DB (většina MVCC) můž být zajímavé toto řešení:

SELECT MAX(id) FROM Tabulka INTO max
WHILE true:
   SELECT * FROM TABULKA WHERE id >= RANDOM() * max INTO rec
   SELECT COALESCE(MAX(id),0) FROM TABULKA WHERE id < rec.id INTO prev_id
   if RANDOM()<1.0/(rec.id - prev_id):
       return rec

   

Myšlenka je doufám jasná: využiju ID, random udělam na díru, a díry ošětřím tak, že záznam "za dírou" vrátím jen v patřičném podílu případů, v opačném selektuju znovu.

Nevýhoda je nedeterministický čas.