Ai fini dell'ottimizzazione, una buona regola pratica è quella di unire meno, non di più. In effetti, dovresti provare a unire il minor numero di righe possibile con il minor numero di righe possibile. Con qualsiasi aggiunta aggiuntiva, moltiplichi il costo invece di aggiungere il costo. Perché mysql fondamentalmente genererà solo una grande matrice moltiplicata. Tuttavia, gran parte di ciò viene ottimizzato da indici e altre cose.
Ma per rispondere alla tua domanda:in realtà è possibile contare con un solo big join, supponendo che i tavoli abbiano chiavi univoche e che idalb sia una chiave univoca per l'album. Quindi, e solo allora, puoi farlo in modo simile al tuo codice:
select alb.titreAlb as "Titre",
count(distinct payalb.idAlb, payalb.PrimaryKeyFields) "Pays",
count(distinct peralb.idAlb, peralb.PrimaryKeyFields) "Personnages",
count(distinct juralb.idAlb, juralb.PrimaryKeyFields) "Jurons"
from album alb
left join pays_album payalb using ( idAlb )
left join pers_album peralb using ( idAlb )
left join juron_album juralb using ( idAlb )
where alb.titreAlb = "LES CIGARES DU PHARAON"
group by alb.titreAlb
dove PrimaryKeyFields sta per i campi della chiave primaria delle tabelle unite (devi cercarli).
Distinct rimuoverà l'effetto che gli altri join hanno sul conteggio. Ma sfortunatamente, in generale, distinct non rimuoverà l'effetto che i join hanno sul costo.
Tuttavia, se hai indici che coprono tutti i campi (idAlb + PrimaryKeyFields) delle tue tabelle, potrebbe essere anche veloce come la soluzione originale (perché può ottimizzare il distinct per non eseguire un ordinamento) e si avvicinerà a ciò a cui stavi pensando (semplicemente esaminando ogni tabella/indice una volta). Ma in uno scenario normale o peggiore, dovrebbe funzionare peggio di una soluzione ragionevole (come quella di SlimGhost) - perché è dubbio che troverà la strategia ottimale. Ma giocaci e controlla le spiegazioni (e pubblica i risultati), forse mysql farà qualcosa di pazzo.
