Odpowiedź Jasona jest na miejscu. Dodatkowo spróbowałbym użyć bardziej nowoczesnej składni złączenia ANSI, aby odciążyć klauzulę WHERE, aby zmniejszyć zamieszanie:
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
To zatrzyma nieumyślne połączenie krzyżowe powodujące eksplozję kombinatoryczną; Spodziewam się, że będzie działać w rozsądnym czasie, chyba że baza danych będzie naprawdę ogromna.
Jeśli nie, czy możesz opublikować wyniki WYBIERZ Z POW. Przypuszczalnie jeden lub oba indeksy pełnotekstowe nie są używane. Z pewnością mógłbym sobie wyobrazić, że optymalizator zapytań nie użyje drugiego indeksu pełnotekstowego, wykonując coś takiego jak próba „wypełnienia” wierszy, które nie pasują do pierwszego zapytania pełnotekstowego, zamiast przechodzenia bezpośrednio do indeksu lub coś takiego.
Zwykle, gdy chcesz indeksować pełnotekstowo w dwóch kolumnach w połączeniu, tworzysz jeden indeks w obu kolumnach. W każdym razie byłoby to znacznie szybsze. Oznaczałoby to jednak, że musisz umieścić tytuły i opisy w tej samej tabeli. To może nie być takie trudne:ponieważ pełny tekst działa tylko w tabelach MyISAM (i zazwyczaj nie chcesz, aby Twoje dane kanoniczne były w tabelach MyISAM), możesz zachować ostateczną kopię swoich danych w odpowiednio znormalizowanych tabelach InnoDB, z dodatkową tabelą MyISAM zawiera tylko przynętę pozbawioną i łodygi.
Jeśli nic z tego nie jest dobre... cóż, myślę, że wrócę do UNIONing, o którym wspomniałeś, w połączeniu z filtrem na poziomie aplikacji, aby usunąć zduplikowane identyfikatory.
