| Autor | Zpráva | ||
|---|---|---|---|
| VelkýBubák Profil |
#1 · Zasláno: 12. 3. 2015, 20:12:35
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 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 zajímalo by mne, zda by to nešlo napsat nějak lépe, ... |
||
| Taps Profil |
#2 · Zasláno: 12. 3. 2015, 21:27:13
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 |
#4 · Zasláno: 13. 3. 2015, 02:07:11
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*/) ... 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. |
||
|
Časová prodleva: 10 let
|
|||
0