Parece que as tabelas InnoDB não permitem pesquisas em vários índices de texto completo no mesmo
MATCH() doença. Aqui seus campos não pertencem todos à mesma tabela, portanto são cobertos por índices diferentes. Observe que a mesma limitação se aplica se você tiver uma tabela como esta:
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
parece uma pesquisa de texto completo pode pesquisar apenas no primeiro índice de texto completo que encontrar mas isso é apenas algo que deduzo a partir desta experiência , por favor, não tome isso como garantido.
A conclusão é que você deve dividir sua pesquisa para usar um único índice de texto completo por
MATCH() cláusula: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...
Esta é uma ilustração de uma possível consulta se você tiver dois índices distintos no
auction e um em user . Você precisa adaptá-lo à sua estrutura real (por favor, poste as descrições de suas tabelas se precisar de mais orientação). Observe que isso se aplica apenas a tabelas InnoDB. Curiosamente, as tabelas MyISAM não parecem mostrar a mesma limitação .
Atualização:acontece que isso foi um bug no mecanismo InnoDB , fixado em 5.6.13/5.7.2. O exemplo acima agora falha com razão com "Não é possível encontrar o índice FULLTEXT correspondente à lista de colunas". De fato, não há índice em
(f1, f2) , mas um em (f1) e outro em (f2) . Como o changelog aconselha :Vale ressaltar que, embora essas consultas retornem um conjunto de resultados correto com o MyISAM, elas são executadas mais lentamente do que o esperado, pois eles ignoram silenciosamente os índices de texto completo existentes .
