Wygląda na to, że tabele InnoDB nie pozwalają na przeszukiwanie kilku indeksów pełnotekstowych w tym samym MATCH()
stan.
Tutaj twoje pola nie należą do tej samej tabeli, dlatego są objęte różnymi indeksami. Zauważ, że to samo ograniczenie obowiązuje, jeśli masz taki stół:
CREATE TABLE t (
f1 VARCHAR(20),
f2 VARCHAR(20),
FULLTEXT(f1), FULLTEXT(f2)
) ENGINE=InnoDB;
SELECT * FROM t
WHERE MATCH(f1, f2) AGAINST ('something in f2'); -- likely to return no row
Wygląda na wyszukiwanie pełnotekstowe może przeszukiwać tylko pierwszy napotkany indeks pełnotekstowy ale jest to tylko coś, co odejmuję z tego doświadczenia , nie bierz tego za pewnik.
Najważniejsze jest to, że powinieneś podzielić wyszukiwanie tak, aby używać jednego indeksu pełnotekstowego na MATCH()
klauzula:
SELECT * FROM auction, user, gallery, ...
WHERE
MATCH(auction.field1, auction.field2) AGAINST ('search query' IN BOOLEAN MODE) OR
MATCH(auction.field3) AGAINST ('search query' IN BOOLEAN MODE) OR
MATCH(user.field1, user.field2, user.field3) AGAINST...
To jest ilustracja możliwego zapytania, jeśli masz dwa różne indeksy na auction
i jeden na user
. Musisz dostosować go do swojej rzeczywistej struktury (proszę zamieścić opisy tabel, jeśli potrzebujesz więcej wskazówek).
Zauważ, że dotyczy to tylko tabel InnoDB. Co ciekawe, tabele MyISAM wydaje się nie wykazują tych samych ograniczeń .
Aktualizacja:okazuje się, że był to błąd w silniku InnoDB
, ustalone w 5.6.13/5.7.2. Powyższy przykład teraz słusznie kończy się niepowodzeniem z „Nie można znaleźć indeksu FULLTEXT pasującego do listy kolumn”. Rzeczywiście, nie ma indeksu w (f1, f2)
, ale jeden na (f1)
i kolejny na (f2)
. Jak radzi dziennik zmian :
Warto zauważyć, że chociaż takie zapytania zwracają poprawny zestaw wyników za pomocą MyISAM, działają wolniej, niż można by się spodziewać, ponieważ po cichu ignorują istniejące indeksy pełnotekstowe .