Newsgroup: it.comp.software.database
Titolo: Performace Query ... ?

C'è qualcosa che mi sfugge:
La famosa tabella da 692.000 record di qualche post sopra...
raggruppo tutte le righe per IDArticolo, faccio una count(*), la metto
in join con la tabella articoli per avere la descrizione e filtro solo
quelli che contengo '%rosso%'...
Su A97 è istantanea...
Su MSSQL2000 ci mette 2 secondi
Su MySQL ci mette 30 secondi
C'è qualche accorgimento che mi sfugge?
Le prestazioni di MySQL non erano buone?
---Cut
mysql> select ar_descrizione, DDM_IDArticolo, count(*) as c from
tbldettdocumovi inner join tblarticolo on DDM_Idarticolo = ar_id group
by DDM_Idarticolo having ar_descrizione like '%verde%' and c > 250
order by c desc;
+--------------------------------+----------------+-----+
| ar_descrizione                 | DDM_IDArticolo | c   |
+--------------------------------+----------------+-----+
| SMALTO C/C 750ml.- Verde bosco |            478 | 453 |
| CERNIT  65gr.-018 verde        |          12514 | 349 |
| Raschietto scrapp lungo verde  |           5007 | 263 |
| CERNIT  65gr.-019 verde chiaro |          12499 | 251 |
+--------------------------------+----------------+-----+
4 rows in set (30.16 sec)
mysql>
-- 
reintermediare processi front-end

Su MySQL ci mette 30 secondi
Ho fermato e riavviato MSSQL2000 e la query ci ha messo 24 secondi...
Forse che dopo un pň si mette in cache qualche risultato?
-- 
reintermediare processi front-end

 Forse che dopo un pò si mette in cache qualche risultato?
se non lo facesse, sarebbe UN PAZZO!!! (ahahahah...) 
li hai creati gli indici sui campi di join? (intanto).
e sui campi con clausola where??
la query è precisa identica sui 3 db?
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/philosophy/motivation.it.html

 order by c desc;
La query è anche sbagliata...
select ar_descrizione, DDM_IDArticolo, count(*) as c
   from tbldettdocumovi
  inner join tblarticolo on DDM_Idarticolo = ar_id
  group by DDM_Idarticolo
<errore>
having ar_descrizione like '%verde%'
</errore>
    and c > 250
  order by c desc;
non vedo il motivo di mettere un condizione di having in questo punto...
La having discrimina il risultato dopo il raggruppamento... ma in questo
caso la descrizione è tale e quale prima e dopo la group by.
Mettila come where e il server sql ti sorriderà... (visto che gli levi
un po di record prima di fare la group by)
/G

La query è anche sbagliata...
pazzesco... hai ragione da vendere!!
la query con la condizione where ci mette 4 secondi la prima volta e
0.45s tutte le altre volte.
Usando QBE per costruire quella query il codice SQL che viene generato
è quello non ottimo che ho postato poco su, che ho utilizzato per fare
i miei test.
Dunque è bastardo Access che usa una dialetto non standard di SQL...
Perchè di fatto riscrivendo la query con la condizione WHERE che mi
hai suggerito MySQL offre le performance migliori.
Ma perchè M$ non segue mai gli standard che esistono già???
-- 
reintermediare processi front-end

 Ma perchè M$ non segue mai gli standard che esistono già???
mo' non facciamo troppe polemiche, nessuno li fuori segue gli
standard 100%... mysql? oracol..? nessuno di certo può lanciare
la prima pietra...
/G

la prima pietra...
beh si... mi ero fatto prendere !!!
non capivo perchč mysql fosse cosě tanto piů lento con la stessa
query...
grazie.
ciao
-- 
reintermediare processi front-end