Para fines de optimización, una buena regla general es unir menos, no más. De hecho, debe intentar unir la menor cantidad de filas posible con la menor cantidad de filas posible. Con cualquier unión adicional, multiplicará el costo en lugar de agregar el costo. Porque mysql básicamente solo generará una gran matriz multiplicada. Sin embargo, mucho de eso se optimiza mediante índices y otras cosas.
Pero para responder a su pregunta:en realidad es posible contar con una sola combinación grande, suponiendo que las tablas tengan claves únicas e idalb es una clave única para el álbum. Entonces, y solo entonces, puedes hacerlo de forma similar a tu código:
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
donde PrimaryKeyFields representa los campos de clave principal de las tablas unidas (debe buscarlas).
Distinct eliminará el efecto que las otras uniones tienen en el conteo. Pero desafortunadamente, en general, distinct no eliminará el efecto que las uniones tienen sobre el costo.
Aunque, si tiene índices que cubren todos los campos (idAlb + PrimaryKeyFields) de sus tablas, eso podría ser incluso tan rápido como la solución original (porque puede optimizar el distinct para no hacer una clasificación) y se acercará a lo que estaba pensando (simplemente recorriendo cada tabla/índice una vez). Pero en un escenario normal o en el peor de los casos, debería funcionar peor que una solución razonable (como la de SlimGhost), porque es dudoso que encuentre la estrategia óptima. Pero juegue con él y verifique las explicaciones (y publique los hallazgos), tal vez mysql haga algo loco.
