Los índices FULLTEXT realmente no son tan rápidos como crees.
Use una tabla separada para almacenar sus etiquetas:
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
......
SELECCIONA todo el contenido con la etiqueta 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;
Debido a la clave externa, todos los campos en tag_links se indexan individualmente.
Las etiquetas `WHERE ='test' seleccionan 1 (!) registro.
Equi-join esto con 10,000 taglinks.
Y Equi-une que con 1 registro de contenido cada uno (cada tag_link solo apunta a 1 contenido).
Debido al límite de 10, MySQL dejará de buscar tan pronto como tenga 10 elementos, por lo que realmente solo busca 10 registros de tag_links.
El content.id se incrementa automáticamente, por lo que los números más altos son un proxy muy rápido para los artículos más nuevos.
En este caso nunca necesita buscar otra cosa que no sea la igualdad y comienza con 1 etiqueta que se une mediante claves enteras (la unión más rápida posible).
No hay si-entonces-o-peros al respecto, esta es la forma más rápida.
Tenga en cuenta que debido a que hay como máximo unas 1000 etiquetas, cualquier búsqueda será mucho más rápida que profundizar en la tabla de contenido completa.
Finalmente
Los campos CSV son una muy mala idea, nunca los use en una base de datos.
