Autor Zpráva
VelkýBubák
Profil
Opravují postarší sql dotazy. Původní seznam duplikací byl řešen takto
select count(id_anidb_postava) as pocet, postavy.* from postavy where id_anidb_postava>0 group by id_anidb_postava having pocet>1
což ovšem vypíše jen jediný záznam z duplikovaných, takže jsem to předělal na
select * from postavy where id_anidb_postava in (select id_anidb_postava from postavy AS aPostavy where exists (select id_anidb_postava, count(id_anidb_postava) AS pocet from postavy where id_anidb_postava>=0 and aPostavy.id_anidb_postava=postavy.id_anidb_postava group by id_anidb_postava having pocet>1)) order by id_anidb_postava
což sice funguje, jak bych chtěl a očekával, ale jak psaní takovýchto výrazů, tak i orientace v nich je ... složitá

zajímalo by mne, zda by to nešlo napsat nějak lépe, ...
Taps
Profil
VelkýBubák:
nezkoušel jsi použít řešení uvedené na Některé časteji řešené dotazy pro MySQL - FAQ » Nalezení duplicit ?
VelkýBubák
Profil
Taps:
Hm, máš pravdu, až teď.
select p1.* from postavy AS p1 JOIN (select p2.id_anidb_postava from postavy AS p2 group by p2.id_anidb_postava HAVING count(id_anidb_postava)>1) AS p3 on p1.id_anidb_postava=p3.id_anidb_postava ORDER BY p3.id_anidb_postava

Hm. Je to kratší zápis, skrýt agregační funkci do klauzule having je asi výhodné (když ji nepotřebuji vypsat), a podstatně se to zrychlilo.
z původních: 347 total, Query took 0.5992 sec, na 347 total, Query took 0.0103 sec.

Škoda že to stále musí jet na třech kopiích (???) totožné tabulky. Navíc by mě docela zajímalo, čím vlastně ta třetí tabulka teď vlasně je ... spojení tabulky p1 a p2 ?

Aha, tak zrychlení asi nesouvisí s tímto dotazem ale spíše s aktuální vytížeností databáze, teď (v 0:35) to bylo 347 total, Query took 0.3852 sec.
Keeehi
Profil
p3 je tabulka s jedním sloupcem ve které jsou idčka duplicitních záznamů. Ten join s p1 je jeden ze způsobů, jak data vyfiltrovat. Samozřejmě by se dalo použít
... WHERE id_anidb_postava IN (/*tvůj subselect*/) ...
OOvšem filtrování pomocí joinu by mělo být rychlejší.

Navíc to přejmenovávání tabulek je zbytečné. U p1 a p2 určitě a myslím že při použít USING (id_anidb_postava) by se dalo odstranit i p3

Provádět benchmark na produkčním serveru pro zjištění, který z dotazů je rychlejší má své výhody i nevýhody. Ovšem to číslo co vidíte vy nevypovídá naprosto o ničem, protože ho ovlivňuje 346 dalších dotazů. Ty sice jsou pořád stejné, ovšem doba jejich vykonání je pokaždé jiná a zanáší vám to do měření neuvěřitelný šum. Pro zjištění zrychlení/zpomalení musíte změřit dobu vykonání jen toho jediného dotazu. Pak vám ta informace k něčemu bude.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: