FULLTEXT-indekser er virkelig ikke så hurtige, som du måske tror, de er.
Brug en separat tabel til at gemme dine 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
......
Du VÆLGER alt indhold med tag x ved at bruge:
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;
På grund af den fremmede nøgle bliver alle felter i tag_links individuelt indekseret.
`WHERE tags ='test' vælger 1 (!) post.
Equi-forener denne med 10.000 taglinks.
Og Equi-joins det med 1 indholdsrecord hver (hvert tag_link peger kun på 1 indhold).
På grund af grænsen 10 stopper MySQL med at lede, så snart det har 10 elementer, så det ser egentlig kun på 10 tag_links-poster.
Content.id er autoinkrementerende, så højere tal er meget hurtig proxy for nyere artikler.
I dette tilfælde skal du aldrig skal lede efter andet end lighed, og du starter med 1 tag, som du equi-join ved hjælp af heltalsnøgler (den hurtigst mulige join).
Der er ingen hvis-så-eller-men om det, dette er den hurtigste måde.
Bemærk, at fordi der højst er et par 1000 tags, vil enhver søgning være meget hurtigere end at dykke ned i hele indholdstabellen.
Endelig
CSV-felter er en meget dårlig idé. Brug den aldrig i en database.