最適化の目的で、経験則として、参加する数を増やすのではなく、減らすことをお勧めします。実際、できるだけ少ない行でできるだけ少ない行を結合するようにしてください。追加の結合を使用すると、コストを追加する代わりにコストを乗算します。 mysqlは基本的に大きな乗算されたマトリックスを生成するだけだからです。ただし、その多くはインデックスやその他のものによって最適化されます。
しかし、あなたの質問に答えるには、テーブルに一意のキーがあり、idalbがアルバムの一意のキーであると仮定すると、実際には1つの大きな結合だけで数えることができます。それから、そしてその時だけ、あなたはあなたのコードと同じようにそれをすることができます：
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
ここで、PrimaryKeyFieldsは、結合されたテーブルの主キーフィールドを表します（それらを検索する必要があります）。
Distinct 他の結合がカウントに与える影響を削除します。しかし、残念ながら、一般的に、distinct 結合がコストに与える影響は削除されません。
ただし、テーブルのすべての（idAlb + PrimaryKeyFields）フィールドをカバーするインデックスがある場合は、元のソリューションと同じくらい高速になる可能性があります（distinctを最適化できるため） 並べ替えを行わないようにします）、考えていたものに近づきます（すべてのテーブル/インデックスを1回ウォークスルーするだけです）。しかし、通常または最悪の場合のシナリオでは、合理的なソリューション（SlimGhostのソリューションなど）よりもパフォーマンスが低下するはずです。最適な戦略が見つかるかどうかは疑わしいためです。しかし、それをいじって説明を確認してください（そして調査結果を投稿してください）、多分mysqlは何かおかしなことをするでしょう。