Voor optimalisatiedoeleinden is een goede vuistregel om minder mee te doen, niet meer. In feite moet je proberen om zo min mogelijk rijen aan te sluiten met zo weinig mogelijk rijen. Met elke extra deelname vermenigvuldigt u de kosten in plaats van de kosten op te tellen. Omdat mysql in feite gewoon een grote vermenigvuldigde matrix zal genereren. Veel daarvan wordt echter weggeoptimaliseerd door indexen en andere dingen.
Maar om je vraag te beantwoorden:het is eigenlijk mogelijk om met slechts één grote join te tellen, ervan uitgaande dat de tabellen unieke sleutels hebben en idalb een unieke sleutel voor album is. Dan, en alleen dan, kun je het op dezelfde manier doen als je code:
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
waarbij PrimaryKeyFields staat voor de primaire sleutelvelden van de samengevoegde tabellen (je moet ze opzoeken).
Distinct verwijdert het effect dat de andere joins hebben op de telling. Maar helaas, in het algemeen, distinct zal het effect dat de joins hebben op de kosten niet wegnemen.
Hoewel, als je indexen hebt die alle (idAlb + PrimaryKeyFields)-velden van je tabellen dekken, dat zelfs zo snel kan zijn als de originele oplossing (omdat het de distinct kan optimaliseren om geen sortering uit te voeren) en komt in de buurt van waar u aan dacht (slechts één keer door elke tabel/index lopen). Maar in een normaal of slechtst geval zou het slechter moeten presteren dan een redelijke oplossing (zoals die van SlimGhost) - omdat het twijfelachtig is dat het de optimale strategie zal vinden. Maar speel ermee en bekijk de uitleg (en post de bevindingen), misschien doet mysql iets geks.