Câu trả lời của Jason là đúng. Ngoài ra, tôi sẽ cố gắng sử dụng cú pháp nối ANSI hiện đại hơn để loại bỏ mệnh đề WHERE để giảm bớt sự nhầm lẫn ở đó:
SELECT o.id
FROM programs o
JOIN titles_programs t ON t.object_id=o.id
JOIN descriptions_programs d ON d.object_id=o.id
WHERE MATCH (d.text) AGAINST ('+china' IN BOOLEAN MODE) AND d.current=1
OR MATCH (t.text) AGAINST ('+china' IN BOOLEAN MODE) AND t.current=1
Điều này sẽ ngăn chặn sự kết hợp chéo vô tình gây ra vụ nổ tổ hợp; Tôi hy vọng nó sẽ hoạt động trong thời gian hợp lý trừ khi cơ sở dữ liệu thực sự khổng lồ.
Nếu không, bạn có thể đăng kết quả của một LỰA CHỌN GIẢI THÍCH ở trên không? Có lẽ một hoặc cả hai chỉ mục văn bản đầy đủ không được sử dụng. Tôi chắc chắn có thể tưởng tượng trình tối ưu hóa truy vấn không sử dụng chỉ mục toàn văn thứ hai, bằng cách làm điều gì đó như cố gắng 'điền vào' các hàng không khớp với truy vấn đầy đủ văn bản đầu tiên thay vì đi thẳng đến chỉ mục hoặc gì đó.
Thông thường khi bạn muốn lập chỉ mục toàn văn bản trên hai cột kết hợp, bạn tạo một chỉ mục trên cả hai cột. Điều này trong mọi trường hợp sẽ nhanh hơn nhiều. Tuy nhiên, nó có nghĩa là bạn phải đặt tiêu đề và mô tả trong cùng một bảng. Đây có thể không phải là một khó khăn như vậy:vì văn bản đầy đủ chỉ hoạt động trên các bảng MyISAM (và bạn thường không muốn dữ liệu chuẩn của mình trong các bảng MyISAM) nên bạn có thể giữ bản sao cuối cùng của dữ liệu của mình trong các bảng InnoDB được chuẩn hóa đúng cách, với một bảng MyISAM bổ sung chỉ chứa mồi tìm kiếm đã tách và có gốc.
Nếu không có điều nào trong số đó là tốt ... tốt, tôi đoán tôi sẽ quay lại UNIONing mà bạn đã đề cập, cùng với bộ lọc cấp ứng dụng để loại bỏ các ID trùng lặp.
