Nếu các chỉ mục được sử dụng đúng cách thì nó hầu như luôn hiệu quả hơn để sử dụng một JOIN. Sự nhấn mạnh được thêm vào bởi vì hiệu quả tốt nhất không phải lúc nào cũng bằng hiệu suất tốt nhất.
Tuy nhiên, không thực sự có một câu trả lời phù hợp với tất cả; bạn nên phân tích một truy vấn bằng cách sử dụng EXPLAIN để đảm bảo rằng các chỉ mục thực sự đang được sử dụng, không có việc sử dụng bảng tạm thời không cần thiết, v.v. Trong một số trường hợp , các điều kiện âm mưu để tạo một truy vấn không thể sử dụng các chỉ mục. Trong những trường hợp đó, nó có thể nhanh hơn để tách các truy vấn thành nhiều phần theo cách bạn đã chỉ định.
Nếu tôi gặp mã như vậy trong một dự án hiện có, tôi sẽ đặt câu hỏi về nó:kiểm tra truy vấn, nghĩ ra các cách khác nhau để thực hiện truy vấn, đảm bảo rằng những điều này đã được xem xét, xây dựng một trường hợp khoa học, hỗ trợ thực tế hoặc chống lại thực tiễn . Đảm bảo rằng các nhà phát triển ban đầu đã thực hiện thẩm định của họ, vì việc không sử dụng JOIN sẽ chỉ dẫn đến cơ sở dữ liệu hoặc thiết kế truy vấn kém. Tuy nhiên, cuối cùng, kết quả có ý nghĩa lớn và nếu tất cả các tối ưu hóa và sửa chữa vẫn dẫn đến kết hợp chậm hơn so với việc sử dụng các đoạn truy vấn được cung cấp, thì giải pháp nhanh hơn sẽ chiếm ưu thế. Điểm chuẩn và hành động dựa trên kết quả của điểm chuẩn; không có trường hợp nào trong thiết kế phần mềm mà bạn nên đánh đổi hiệu suất kém để bám vào các quy tắc tùy ý về những gì bạn nên làm hoặc không nên làm. Phương pháp hoạt động tốt nhất là phương pháp tốt nhất.
