Crie três índices de texto completo
- a) um na coluna de palavra-chave
- b) um na coluna de conteúdo
- c) um na coluna de palavra-chave e conteúdo
Então, sua consulta:
SELECT id, keyword, content,
MATCH (keyword) AGAINST ('watermelon') AS rel1,
MATCH (content) AGAINST ('watermelon') AS rel2
FROM table
WHERE MATCH (keyword,content) AGAINST ('watermelon')
ORDER BY (rel1*1.5)+(rel2) DESC
A questão é que
rel1 fornece a relevância de sua consulta apenas na keyword coluna (porque você criou o índice apenas nessa coluna). rel2 faz o mesmo, mas para o content coluna. Agora você pode adicionar essas duas pontuações de relevância aplicando qualquer ponderação que desejar. No entanto, você não está usando nenhum desses dois índices para a pesquisa real. Para isso, você usa seu terceiro índice, que está nas duas colunas.
O índice em (palavra-chave, conteúdo) controla sua recuperação. Aka, o que é devolvido.
Os dois índices separados (um apenas para palavras-chave e outro apenas para conteúdo) controlam sua relevância. E você pode aplicar seus próprios critérios de ponderação aqui.
Observe que você pode usar qualquer número de índices diferentes (ou, variar os índices e pesos que você usa no momento da consulta com base em outros fatores talvez ... apenas pesquise por palavra-chave se a consulta contiver uma palavra de parada ... diminua o viés de ponderação para palavras-chave se a consulta contiver mais de 3 palavras ... etc).
Cada índice consome espaço em disco, portanto, mais índices, mais disco. E, por sua vez, maior consumo de memória para mysql. Além disso, as inserções levarão mais tempo, pois você terá mais índices para atualizar.
Você deve avaliar o desempenho (tendo o cuidado de desligar o cache de consulta mysql para benchmarking, caso contrário seus resultados serão distorcidos) para sua situação. Isso não é eficiente no Google Grade, mas é bem fácil e "pronto para uso" e quase certamente é muito melhor do que o uso de "curtir" nas consultas.
Acho que funciona muito bem.
