FULLTEXT индексите наистина не са толкова бързи, колкото си мислите.
Използвайте отделна таблица, за да съхранявате вашите тагове:
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
......
Избирате цялото съдържание с маркер x, като използвате:
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;
Поради външния ключ всички полета в tag_links се индексират поотделно.
Таговете `WHERE ='test' избират 1 (!) запис.
Equi-присъединява това с 10 000 taglink.
И Equi-присъединявато с по 1 запис за съдържание (всяка tag_link винаги сочи към 1 съдържание).
Поради ограничението 10 MySQL ще спре да търси веднага щом има 10 елемента, така че наистина разглежда само 10 tag_links записа.
Content.id се увеличава автоматично, така че по-високите числа са много бързи прокси за по-нови статии.
В този случай виеникогате трябва да потърсите нещо различно от равенство и започвате с 1 таг, който екви-съединявате с помощта на целочислени ключове (най-бързото възможно присъединяване).
За това няма „ако-тогава-или-но“, това е най-бързият начин.
Имайте предвид, че тъй като има най-много няколко 1000 маркера, всяко търсене ще бъде много по-бързо от задълбочаването в таблицата с пълно съдържание.
Най-накрая
CSV полетата са много лоша идея, никога не ги използвайте в база данни.
