Đối với mục đích tối ưu hóa, một nguyên tắc chung là tham gia ít hơn, không tham gia nhiều hơn. Trên thực tế, bạn nên cố gắng nối càng ít hàng càng tốt với càng ít hàng càng tốt. Với bất kỳ tham gia bổ sung nào, bạn sẽ nhân chi phí thay vì cộng thêm chi phí. Bởi vì về cơ bản mysql sẽ chỉ tạo ra một ma trận được nhân lớn. Mặc dù vậy, rất nhiều thứ được tối ưu hóa bằng chỉ mục và những thứ khác.
Nhưng để trả lời câu hỏi của bạn:thực sự có thể đếm chỉ với một phép nối lớn, giả sử các bảng có các khóa duy nhất và idalb là khóa duy nhất cho album. Sau đó, và chỉ sau đó, bạn có thể làm điều đó tương tự như mã của bạn:
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
trong đó PrimaryKeyFields là viết tắt của các trường khóa chính của các bảng đã nối (bạn phải tra cứu chúng).
Distinct sẽ loại bỏ hiệu ứng mà các phép nối khác có đối với số lượng. Nhưng thật không may, nói chung, distinct sẽ không loại bỏ ảnh hưởng của các phép nối đối với chi phí.
Mặc dù, nếu bạn có các chỉ mục bao gồm tất cả các trường (idAlb + PrimaryKeyFields) trong bảng của mình, thì điều đó thậm chí có thể nhanh như giải pháp ban đầu (vì nó có thể tối ưu hóa distinct để không thực hiện sắp xếp) và sẽ đến gần với những gì bạn đang nghĩ đến (chỉ cần xem qua mỗi bảng / chỉ mục một lần). Nhưng trong trường hợp szenario bình thường hoặc trường hợp xấu nhất, nó sẽ hoạt động kém hơn một giải pháp hợp lý (như giải pháp của SlimGhost) - bởi vì người ta nghi ngờ nó sẽ tìm ra chiến lược tối ưu. Nhưng hãy thử với nó và kiểm tra các giải thích (và đăng các phát hiện), có thể mysql sẽ làm điều gì đó điên rồ.
