[SQL] Prestazioni di una query annidata

[cicciopasticcio1]

Il mio dubbio è su questa piccola query:

SELECT *
FROM MATCHES 
WHERE UPDATE_TIME > 
      (SELECT UPDATE_TIME 
      FROM SESSIONS 
      WHERE NOT UPDATED AND SID = 'abc')

La query si ferma se la query annidata ritorna un recordset vuoto? Non vorrei che andasse ad aprirmi la tabella MATCHES senza essercene bisogno!

Cambiando l'ordine delle condizioni

WHERE AND SID = 'abc' AND NOT UPDATED

Si ottiene un vantaggio dal punto di vista prestazionale ?

Magari ipotizzando che SID è un indice univoco a 32 caratteri e più o meno una sessione su due ha UPDATED fissato a FALSE.

Grazie mille a chi si interesserà! Preciso che il dbms è apache derby, ma immagino sia poco influente visto che la gestione dovrebbe essere bene o male simile per tutti i dbms.

[The_ouroboros]

Originariamente inviato da cicciopasticcio1

Il mio dubbio è su questa piccola query:

SELECT *
FROM MATCHES 
WHERE UPDATE_TIME > 
      (SELECT UPDATE_TIME 
      FROM SESSIONS 
      WHERE NOT UPDATED AND SID = 'abc')

La query si ferma se la query annidata ritorna un recordset vuoto? Non vorrei che andasse ad aprirmi la tabella MATCHES senza essercene bisogno!

Cambiando l'ordine delle condizioni


Si ottiene un vantaggio dal punto di vista prestazionale ?

Magari ipotizzando che SID è un indice univoco a 32 caratteri e più o meno una sessione su due ha UPDATED fissato a FALSE.

Grazie mille a chi si interesserà! Preciso che il dbms è apache derby, ma immagino sia poco influente visto che la gestione dovrebbe essere bene o male simile per tutti i dbms.

più che altro è quel * a fare cose che non sono nesessarie (occupare cpu/ram).
Sempre meglio specificare i campi necessari.

P.S ma recordset vuote è = 0?

[cicciopasticcio1]

Originariamente inviato da The_ouroboros

più che altro è quel * a fare cose che non sono nesessarie (occupare cpu/ram).
Sempre meglio specificare i campi necessari.

P.S ma recordset vuote è = 0?

Ho messo il * perchè mi servono veramente tutti i campi, dal primo all'ultimo.

Con recordSet vuoto intendo:

      (SELECT UPDATE_TIME 
      FROM SESSIONS 
      WHERE NOT UPDATED AND SID = 'abc')

che non torna nessun risultato! 0 record. La prima select select vedrebbe UPDATE_TIME > [qualcosa che non so come venga interpretato (recordset vuoto)] e non so come si comporti.

Dato che deve essere chiamata centinaia di volte al minuto, è indispensabile che dopo che il select interno non abbia prodotto risultati la query si fermi là e lasci stare l'altra tabella, che è anche piuttosto grande.

[The_ouroboros]

Originariamente inviato da cicciopasticcio1

Ho messo il * perchè mi servono veramente tutti i campi, dal primo all'ultimo.

Con recordSet vuoto intendo:

      (SELECT UPDATE_TIME 
      FROM SESSIONS 
      WHERE NOT UPDATED AND SID = 'abc')

che non torna nessun risultato! 0 record. La prima select select vedrebbe UPDATE_TIME > [qualcosa che non so come venga interpretato (recordset vuoto)] e non so come si comporti.

Dato che deve essere chiamata centinaia di volte al minuto, è indispensabile che dopo che il select interno non abbia prodotto risultati la query si fermi là e lasci stare l'altra tabella, che è anche piuttosto grande.

quello che mi domandavo anche io.
Fai una prova con qualcosa che sai essere vuoto e vedi come si comporta e in base a quello ti regoli, no?

[The_ouroboros]

ripensandoci.
(*) (SELECT UPDATE_TIME
FROM SESSIONS
WHERE NOT UPDATED AND SID = 'abc')

Se la (*) ha un risultato è ok.
Se ne ha 0 ti restituisce NULL e quindi scazza.
Se hai + di un risultato sei finito e schianti il DB.

Gli operatori > e < sono binari alla fine.

Che db usi, tanto per sapere.

[VICIUS]

Originariamente inviato da cicciopasticcio1

Il mio dubbio è su questa piccola query:

SELECT *
FROM MATCHES 
WHERE UPDATE_TIME > 
      (SELECT UPDATE_TIME 
      FROM SESSIONS 
      WHERE NOT UPDATED AND SID = 'abc')

La query si ferma se la query annidata ritorna un recordset vuoto? Non vorrei che andasse ad aprirmi la tabella MATCHES senza essercene bisogno!

Cambiando l'ordine delle condizioni


Si ottiene un vantaggio dal punto di vista prestazionale ?

Magari ipotizzando che SID è un indice univoco a 32 caratteri e più o meno una sessione su due ha UPDATED fissato a FALSE.

Grazie mille a chi si interesserà! Preciso che il dbms è apache derby, ma immagino sia poco influente visto che la gestione dovrebbe essere bene o male simile per tutti i dbms.

Se la subquery ritorna il vuoto la where della select principale è impossibile quindi non viene eseguita e ha costo 0.

L'ordine degli operandi non importa ci pensa il db a scegliere l'ordine migliore in base agli indici che ha a disposizione.

[cicciopasticcio1]

Perfetto, quindi la query non ha problemi, il dbms

The_ouroboros: una query senza risultati non restituisce null !

Nel caso torni più di un risultato (cosa impossibile, pura curiosità) il dbms come si comporta, va in errore immagino.

Ah, uso apache derby, come scritto nel primo post!

Grazie!

[The_ouroboros]

Originariamente inviato da cicciopasticcio1

The_ouroboros: una query senza risultati non restituisce null !


Grazie!

Ne sei sicuro?



Inviato dal mio HUAWEI U8825-1 con Tapatalk 2

[cicciopasticcio1]

Originariamente inviato da The_ouroboros

Ne sei sicuro?

Eh si, l'ha detto VICIUS e del resto è anche prevedibile che doveva essere così (del resto NULL è ben diverso dall'insieme vuoto).

[The_ouroboros]

Originariamente inviato da cicciopasticcio1

Eh si, l'ha detto VICIUS e del resto è anche prevedibile che doveva essere così (del resto NULL è ben diverso dall'insieme vuoto).

ha detto che è impossibile non che non è NULL

[cicciopasticcio1]

Originariamente inviato da The_ouroboros

ha detto che è impossibile non che non è NULL

No, ha detto che la query principale è impossibile dal momento che la subquery torna un vuoto

(da quanto ho capito) anche se la subquery tornasse un NULL (non è il nostro caso) la query principale sarebbe impossibile dato che (leggendo questa pagina http://en.wikipedia.org/wiki/Null_%28SQL%29) la condizione INT > NULL non si verifica mai.

[cdimauro]

Originariamente inviato da VICIUS

L'ordine degli operandi non importa ci pensa il db a scegliere l'ordine migliore in base agli indici che ha a disposizione.

Dipende dal DBMS. MySQL, ad esempio, ha forti problemi con le subquery, che non riesce a trasformare in join et similia o a sfruttare gli indici, e capita non di rado che una query semplice si trasformi in una table scan... ripetuta parecchie volte.

[The_ouroboros]

Originariamente inviato da cdimauro

Dipende dal DBMS. MySQL, ad esempio, ha forti problemi con le subquery, che non riesce a trasformare in join et similia o a sfruttare gli indici, e capita non di rado che una query semplice si trasformi in una table scan... ripetuta parecchie volte.

davero?

[VICIUS]

Originariamente inviato da The_ouroboros

davero?

Si per via di come costruisce le join internamente mysql ha sempre avuto problemi con quel genere di query. Diciamo che a volte cerca di aiutare la subquery spostando una o più condizioni dalla principale a quella annidata ma facendolo a volte fa casini.

Quella postata così a naso non dovrebbe avere problemi.

[The_ouroboros]

Originariamente inviato da VICIUS

Si per via di come costruisce le join internamente mysql ha sempre avuto problemi con quel genere di query. Diciamo che a volte cerca di aiutare la subquery spostando una o più condizioni dalla principale a quella annidata ma facendolo a volte fa casini.

Quella postata così a naso non dovrebbe avere problemi.

ri ringrazio per le utili info