Dla celów optymalizacji dobrą zasadą jest dołączanie mniej, a nie więcej. W rzeczywistości powinieneś spróbować połączyć jak najmniej rzędów z jak najmniejszą liczbą rzędów. Z każdym dodatkowym połączeniem pomnożysz koszt zamiast dodawać koszt. Ponieważ mysql po prostu wygeneruje dużą zwielokrotnioną macierz. Wiele z nich zostaje jednak zoptymalizowanych przez indeksy i inne rzeczy.
Ale odpowiadając na twoje pytanie:w rzeczywistości można liczyć za pomocą tylko jednego dużego sprzężenia, zakładając, że stoły mają unikalne klucze, a idalb jest unikalnym kluczem dla albumu. Wtedy i tylko wtedy możesz zrobić to podobnie do swojego kodu:
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
gdzie PrimaryKeyFields oznacza pola klucza głównego połączonych tabel (musisz je sprawdzić).
Distinct usunie wpływ innych sprzężeń na zliczanie. Ale niestety, ogólnie rzecz biorąc, distinct nie usunie wpływu, jaki połączenia mają na koszt.
Chociaż, jeśli masz indeksy, które obejmują wszystkie pola (idAlb + PrimaryKeyFields) twoich tabel, może to być nawet tak szybkie, jak oryginalne rozwiązanie (ponieważ może zoptymalizować distinct aby nie dokonywać sortowania) i zbliży się do tego, o czym myślałeś (po prostu przechodząc przez każdą tabelę/indeks raz). Ale w normalnym lub najgorszym przypadku szenario powinno działać gorzej niż rozsądne rozwiązanie (jak SlimGhost) - bo wątpliwe, czy znajdzie optymalną strategię. Ale pobaw się tym i sprawdź wyjaśnienia (i opublikuj wyniki), może mysql zrobi coś szalonego.
