Índices FULLTEXT realmente não são tão rápidos quanto você pensa que são.
Use uma tabela separada para armazenar suas tags:
Table tags
----------
id integer PK
tag varchar(20)
Table tag_link
--------------
tag_id integer foreign key references tag(id)
content_id integer foreign key references content(id)
/* this table has a PK consisting of tag_id + content_id */
Table content
--------------
id integer PK
......
Você SELECIONA todo o conteúdo com a tag x usando:
SELECT c.* FROM tags t
INNER JOIN tag_link tl ON (t.id = tl.tag_id)
INNER JOIN content c ON (c.id = tl.content_id)
WHERE tag = 'test'
ORDER BY tl.content_id DESC /*latest content first*/
LIMIT 10;
Por causa da chave estrangeira, todos os campos em tag_links são indexados individualmente.
O `WHERE tags ='test' seleciona 1 (!) registro.
Equi-junta isso com 10.000 taglinks.
E Equi-junta-se que com 1 registro de conteúdo cada (cada tag_link sempre aponta para 1 conteúdo).
Devido ao limite de 10, o MySQL parará de procurar assim que tiver 10 itens, então ele realmente só olha para 10 registros de tag_links.
/>O content.id é autoincrementável, então números mais altos são um proxy muito rápido para artigos mais novos.
Nesse caso, você nunca precisa procurar por qualquer coisa além de igualdade e você começa com 1 tag que você associa usando chaves inteiras (a junção mais rápida possível).
Não há se-então-ou-mas sobre isso, este é o caminho mais rápido.
Observe que, como existem no máximo 1.000 tags, qualquer pesquisa será muito mais rápida do que pesquisar o índice completo.
Finalmente
Campos CSV são uma péssima ideia, nunca use-os em um banco de dados.
