För optimeringsändamål är en bra tumregel att gå med mindre, inte mer. I själva verket bör du försöka gå med så få rader du kan med så få rader du kan. Med ytterligare anslutning, multiplicerar du kostnaden istället för att lägga till kostnaden. Eftersom mysql i princip bara genererar en stor multiplicerad matris. Men mycket av det optimeras bort av index och andra saker.
Men för att svara på din fråga:det är faktiskt möjligt att räkna med bara en stor join, förutsatt att tabellerna har unika nycklar och idalb är en unik nyckel för album. Sedan, och först då, kan du göra det på samma sätt som din kod:
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
där PrimaryKeyFields står för de primära nyckelfälten för de sammanfogade tabellerna (du måste slå upp dem).
Distinct kommer att ta bort effekten som de andra kopplingarna har på räkningen. Men tyvärr, i allmänhet, distinct kommer inte att ta bort effekten som sammanfogningarna har på kostnaden.
Även om du har index som täcker alla (idAlb + PrimaryKeyFields)-fält i dina tabeller, kan det vara lika snabbt som den ursprungliga lösningen (eftersom den kan optimera distinct att inte göra en sortering) och kommer nära det du tänkte på (bara gå igenom varje tabell/index en gång). Men i ett normalt eller värsta fall borde det fungera sämre än en rimlig lösning (som SlimGhosts) - eftersom det är tveksamt att den kommer att hitta den optimala strategin. Men lek med det och kolla förklararna (och lägg upp resultaten), kanske mysql kommer att göra något galet.