SQL select molto lenta

[123delphi321]

Ciao a tutti,

ho 2 tabelle in relazione Master/Detail.

Movimenti (9229 records)
MovimentiDetail (29558 records)

ho questa query che viene eseguita in molto tempo (circa 10minuti)

select 
movimentidetail.id
from movimentidetail 
where movimentidetail.idmovimenti in 
( 
select distinct 
movimenti.idassociato 
from movimenti 
)

cercando suggerimenti in rete la ho poi midificata cosi:

 	select
movimentidetail.id
from movimentidetail
inner join movimenti on (movimenti.id=movimentidetail.idassociato)

il risultato inteso come dati è lo stesso, ma la seconda è veloce!!! impiega circa 1 secondo.

c'e' qualcosa che non mi è chiaro...perche la prima query risulta cosi lenta?

premesso che il risultato di
select distinct
movimenti.idassociato
from movimenti
e molto veloce....

forse SQL la esegue per ogni record della tabella MovimentiDetail prima di includere/esclidere il record nel dataresult?

qualcuno mi sa spiegare perfavore?

grazie

[optime]

perché è SQL, bellezza! Le JOIN servono proprio a questo: a velocizzare laddove c'è un minimo di relazione tra due tabelle (il motore fa tutto internamente). Altrimente deve:
1. capire che c'è una query interna
2. eseguirla
3. mettere il risultato in una tabella temporanea
4. inventarsi la JOIN tra la prima tabella e quella temporanea
5. finalmente! fa la query che ti serve

[sspintux]

123delphi321 ... stai per caso usando MySQL ?

[123delphi321]

ciao, no io uso Firebird 2.5

grazie per le risposte

[sspintux]

ciao, no io uso Firebird 2.5

grazie per le risposte

grazie a te ... così aggiungo FireBird all'elenco dei dbms da evitare

[123delphi321]

perche' da evitare?

[sspintux]

Premetto che non ho mai usato Firebird per cui quanto segue
sono solo mie personalissime considerazioni non supportate dalla prova dei fatti.

Fai, a parita' di condizioni, la stessa prova con altri dbms
tipo, per esempio, sql server o mariadb od oracle.

IMHO, quel tipo di comportamento potrebbe indicare un qualche problema
nella progettazione od implementazione del dbms che potrebbe nasconderne anche altri
di cui non te ne accorgi fino a che il carico del db non diventa consistente
... e ti assicuro che in situazioni non banani passare da un dbms
ad un altro e' spesso doloroso (senza contare il downtime)

...comunque se il carico è modesto o hai fatto i test di carico
e sei sicuro che non variera' considerevolmente stai sereno

[nman]

movimenti.idassociato
.......
movimentidetail.idassociato
.........
il risultato inteso come dati è lo stesso

Certamente sono io che non capisco qualcosa
ma le 2 query che dici abbiano lo stesso risultato non possono averlo ...... salvo degli accrocchi inimmaginabili......

Spiegaci quale tabella si trova il campo "idassociato" ????

.

[optime]

nman, a me pare che -- leggendo le due query -- sia verosimile che i risultati siano gli stessi. solo che la prima -- per le ragioni che ho spiegato -- va più lentamente

[nman]

Certamente sono SuperArrugginito, poi si somma anche l'influenza e l'otite ....... e il riscaldamento che non funziona
Certamente le ragioni che esponi nel #2 sono validissime


Mahhhh!!!!
mettiamo il caso che sia corretta la 2° query del #1
... on (movimenti.id=movimentidetail.idassociato)


allora la 1° query per corrispondere dovrebbe essere
... where movimentidetail.idassociato in (select distinct movimenti.id from movimenti)


invece 123delphi321 ci dice che è
... where movimentidetail.idmovimenti in (select distinct movimenti.idassociato from movimenti)


e se i suoi risultati sono uguali significa che c'è qualcosa che ci sfugge .......

.