Eu não estou entendendo isso.

Eu tenho uma tabela com esses índices

PRIMARY     post_id
INDEX       topic_id
FULLTEXT    post_text

A tabela possui (apenas) 346 000 linhas. Estou tentando realizar 2 consultas.

SELECT post_id 
FROM phpbb_posts 
WHERE topic_id = 144017 
AND post_id != 155352 
AND MATCH(post_text) AGAINST('http://rapidshare.com/files/5494794/photo.rar')

leva 4,05 segundos enquanto

SELECT post_id 
FROM phpbb_posts 
WHERE topic_id=144017 
AND post_id != 155352 
AND post_text LIKE ('%http://rapidshare.com/files/5494794/photo.rar%')

leva 0,027 segundos.

EXPLAIN mostra que a única diferença está em possible_keys ( fulltextinclui post_text, LIKEnão)

Isso é realmente estranho.

O que há por trás disso? O que está acontecendo em segundo plano? Como pode LIKEser tão rápido quando não está usando o índice e o FULLTEXT tão lento quando está usando o seu índice?

UPDATE1:

Na verdade, agora leva cerca de 0,5 segundos, talvez a tabela esteja bloqueada, mas ainda assim, quando ligo o perfil, é mostrado que a INICIALIZAÇÃO DO FULLTEXT levou 0,2 segundos. E aí?

Posso consultar minha tabela com LIKE10x por segundo, com texto completo apenas 2x

UPDATE2:

Surpresa!

mysql> SELECT post_id FROM phpbb_posts WHERE post_id != 2 AND topic_id = 6 AND MATCH(post_text) AGAINST ('rapidshare.com');
Empty set (0.04 sec)

então eu estou perguntando, como isso é possível?

Além disso,

SELECT count(*) FROM phpbb_posts WHERE MATCH(post_text) AGAINST ('rapidshare.com')

é muito lento. O texto completo pode estar quebrado?

UPDATE3:

Que diabos?

SELECT forum_id, post_id, topic_id, post_text  FROM phpbb_posts  WHERE MATCH(post_text) AGAINST ('rapidshare.com') LIMIT 0, 30;

leva 0,27s enquanto

SELECT count(*) FROM phpbb_posts  WHERE MATCH(post_text) AGAINST ('rapidshare.com') LIMIT 0, 30;

leva mais de 30 segundos! o que há de errado aqui?

Eu acho que o problema pode resultar da presença do próprio índice FULLTEXT.

Sempre que há uma consulta envolvendo um índice FULLTEXT, o MySQL Query Optimizer tende a atacar a consulta em uma verificação completa da tabela. Eu tenho visto isso ao longo dos anos. Também escrevi um post anterior sobre esse comportamento mais insignificante nos índices do FULLTEXT .

Você pode precisar fazer duas coisas:

1. refatorar a consulta para que o índice FULLTEXT não jogue o MySQL Query Optimizer em um estado de confusão
2. Adicione um índice adicional que ofereça suporte adequado à consulta refatorada

REFator A Consulta

Aqui está sua consulta original

SELECT post_id  
FROM phpbb_posts  
WHERE topic_id = 144017  
AND post_id != 155352  
AND MATCH(post_text) AGAINST('http://rapidshare.com/files/5494794/photo.rar') 

Você precisará refatorar a consulta assim:

SELECT subqueryA.post_id
FROM
(
    SELECT post_id FROM phpbb_posts
    WHERE topic_id = 144017
    AND post_id != 155352
) subqueryA
INNER JOIN
(
    SELECT post_id FROM phpbb_posts
    WHERE MATCH(post_text) AGAINST('http://rapidshare.com/files/5494794/photo.rar')
) subqueryB
USING (post_id);

CRIAR UM NOVO ÍNDICE

Você precisará de um índice para dar suporte subqueryA. Você já tem um índice ativado topic_id. Você precisa substituí-lo da seguinte maneira:

ALTER TABLE phpbb_posts ADD INDEX topic_post_ndx (topic_id,post_id);
ALTER TABLE phpbb_posts DROP INDEX topic_id;

De uma chance !!!

UPDATE 2012-03-19 13:08 EDT

Experimente este primeiro

SELECT post_id FROM
(
    SELECT * FROM phpbb_posts
    WHERE topic_id = 144017
    AND post_id != 155352
) A;

Se isso for rápido e retornar um pequeno número de linhas, tente esta subconsulta aninhada:

SELECT post_id FROM
(
    SELECT * FROM phpbb_posts
    WHERE topic_id = 144017
    AND post_id != 155352
) A
WHERE MATCH(post_text) AGAINST('http://rapidshare.com/files/5494794/photo.rar');

UPDATE 2012-03-19 13:11 EDT

Compare o tempo de execução disso:

SELECT count(*) FROM phpbb_posts  WHERE MATCH(post_text) AGAINST ('rapidshare.com') LIMIT 0, 30;

com isso

SELECT count(*) FROM phpbb_posts WHERE 1 = 1;

Se o tempo de execução for o mesmo, a cláusula MATCH será executada em todas as linhas. Como mencionei anteriormente, o uso de índices FULLTEXT tende a anular quaisquer benefícios tentados e contribuídos pelo MySQL Query Optimizer.