Pagina 3 di 3 primaprima 1 2 3
Visualizzazione dei risultati da 21 a 26 su 26

Discussione: Join consiglio

  1. #21
    Utente di HTML.it L'avatar di MySQL
    Registrato dal
    May 2015
    Messaggi
    729
    Quote Originariamente inviata da optime Visualizza il messaggio
    più lente? hai dei benchmark?
    IO sì
    In questo caso si sta parlando specificamente di MySQL, che per molto tempo non ha avuto un materializzatore delle subquery dipendenti. In sostanza invece di creare una lista di chiavi (nella subquery) per poi eseguire il ciclo esterno (quindi complessità n * 1), eseguiva ogni volta la subquery, quindi complessità n*m (in realtà anche più perchè le chiave per iN in mysql vengono sortate)

    Bene questo è un problema noto e stranoto: le versioni più moderne (credo dalla 5.6 in poi), e mariadb, usano strategie più efficienti, tanto che oggi è difficile dire a priori quale sia meglio (IN o JOIN).

    Siccome, però, spesso gli host a basso costo usano versioni mysql non aggiornate (5.1 anche) il modo migliore è fare un explain della select per vedere cosa succede, o fare una rapida ricerca per vedere se la versione specifica gestisce in modo furbo questo tipo di interrogazioni.

    Il perchè ciò accada, ed accadesse, è relativo alla possibilità di avere interferenze "strane" durante l'esecuzione, uso di funzioni, stored, transazioni pendenti e abortite e così via.
    Per non sbagliare mysql vecchio... ricalcola ogni volta la subquery e buonanotte, è sicuro che i dati siano giusti

  2. #22
    Quote Originariamente inviata da MySQL Visualizza il messaggio
    IO sì
    In questo caso si sta parlando specificamente di MySQL, che per molto tempo non ha avuto un materializzatore delle subquery dipendenti. In sostanza invece di creare una lista di chiavi (nella subquery) per poi eseguire il ciclo esterno (quindi complessità n * 1), eseguiva ogni volta la subquery, quindi complessità n*m (in realtà anche più perchè le chiave per iN in mysql vengono sortate)

    Bene questo è un problema noto e stranoto: le versioni più moderne (credo dalla 5.6 in poi), e mariadb, usano strategie più efficienti, tanto che oggi è difficile dire a priori quale sia meglio (IN o JOIN).

    Siccome, però, spesso gli host a basso costo usano versioni mysql non aggiornate (5.1 anche) il modo migliore è fare un explain della select per vedere cosa succede, o fare una rapida ricerca per vedere se la versione specifica gestisce in modo furbo questo tipo di interrogazioni.

    Il perchè ciò accada, ed accadesse, è relativo alla possibilità di avere interferenze "strane" durante l'esecuzione, uso di funzioni, stored, transazioni pendenti e abortite e così via.
    Per non sbagliare mysql vecchio... ricalcola ogni volta la subquery e buonanotte, è sicuro che i dati siano giusti
    Grazie, e' bello ogni tanto leggere un post tecnico un "pochino" piu' approfondito della media

  3. #23
    Quote Originariamente inviata da k.b Visualizza il messaggio
    Grazie, e' bello ogni tanto leggere un post tecnico un "pochino" piu' approfondito della media
    A prescindere dalla qualità del post ,vorrei capire quale query utilizzare per estrarre quello di cui ho bisogno

  4. #24
    Utente di HTML.it L'avatar di MySQL
    Registrato dal
    May 2015
    Messaggi
    729
    Qui ho trovato una sorta di "summa" molto chiara
    https://mariadb.com/kb/en/mariadb/subquery-optimizations-map/

    Qualche link per i vecchi MySQL
    https://dev.mysql.com/doc/refman/5.1...trictions.html

    Per la scelta su MySQL
    https://dev.mysql.com/doc/refman/5.5...th-exists.html
    e
    https://dev.mysql.com/doc/refman/5.5...ubqueries.html

    A pag. 9 c'è un rapido raffronto con e senza "furbizia": il tempo di esecuzione passa da più di 1,5 ore a 3,2 secondi (per chi chiedeva cosa cambia)


    Insomma la questione non è per nulla banale per MySQL, mentre per MariaDB la situazione è migliore
    Ho trovato qualche slide di 4 anni fa per MariaDB, giusto per mostrare come si tratta di un problema a lungo sentito
    http://cdn.oreillystatic.com/en/asse...esentation.pdf
    Ultima modifica di MySQL; 28-05-2015 a 18:16

  5. #25
    Quote Originariamente inviata da MySQL Visualizza il messaggio
    Qui ho trovato una sorta di "summa" molto chiara
    https://mariadb.com/kb/en/mariadb/subquery-optimizations-map/

    Qualche link per i vecchi MySQL
    https://dev.mysql.com/doc/refman/5.1...trictions.html

    Per la scelta su MySQL
    https://dev.mysql.com/doc/refman/5.5...th-exists.html
    e
    https://dev.mysql.com/doc/refman/5.5...ubqueries.html

    A pag. 9 c'è un rapido raffronto con e senza "furbizia": il tempo di esecuzione passa da più di 1,5 ore a 3,2 secondi (per chi chiedeva cosa cambia)


    Insomma la questione non è per nulla banale per MySQL, mentre per MariaDB la situazione è migliore
    Ho trovato qualche slide di 4 anni fa per MariaDB, giusto per mostrare come si tratta di un problema a lungo sentito
    http://cdn.oreillystatic.com/en/asse...esentation.pdf

    Come detto in precedenza non mi interessa almeno per ora la velocità , devo solo tradurre in SQL:

    Trova tutti i campi di annunci(a.*) ,il nome del comune(c.comune) ,degli utenti che vivono in uno dei comuni (u.citta) della provincia che ho inserito (p.provincia=$_POST[provincia']) e gli annunci devono essere attivi (a.attiva=1)
    Ultima modifica di pippuccio76; 28-05-2015 a 19:51

  6. #26
    Quote Originariamente inviata da pippuccio76 Visualizza il messaggio
    Come detto in precedenza non mi interessa almeno per ora la velocità , devo solo tradurre in SQL:

    Trova tutti i campi di annunci(a.*) ,il nome del comune(c.comune) ,degli utenti che vivono in uno dei comuni (u.citta) della provincia che ho inserito (p.provincia=$_POST[provincia']) e gli annunci devono essere attivi (a.attiva=1)
    Io la query te l'avevo postata! Non mi sembra che quella che tu hai provato sia proprio come quella che ti avevo scritto. hai tolto una condizione!
    "Mai discutere con un idiota. Ti trascina al suo livello e ti batte con l'esperienza." (Oscar Wilde)

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2026 vBulletin Solutions, Inc. All rights reserved.