Indeksy PEŁNOTEKSTOWE naprawdę nie są tak szybkie, jak mogłoby się wydawać.
Użyj oddzielnej tabeli do przechowywania tagów:
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
......
WYBIERZ całą zawartość z tagiem x za pomocą:
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;
Ze względu na klucz obcy wszystkie pola w tag_links są indywidualnie indeksowane.
Karta `WHERE tags ='test' wybiera 1 (!) rekord.
Equi-łączy to z 10 000 tagów.
I Equi łączy to z 1 rekordem zawartości każdy (każdy tag_link zawsze wskazuje tylko 1 zawartość).
Ze względu na limit 10, MySQL przestanie szukać, gdy tylko będzie miał 10 elementów, więc tak naprawdę patrzy tylko na 10 rekordów tag_links.
Content.id zwiększa się automatycznie, więc wyższe liczby są bardzo szybkim serwerem proxy dla nowszych artykułów.
W takim przypadku nigdy musisz szukać czegokolwiek innego niż równość i zaczynasz od 1 tagu, który łączysz równo przy użyciu kluczy całkowitych (najszybsze możliwe łączenie).
Nie ma w tym przypadku „jeśli-to-ale-ale”, to najszybszy sposób.
Zwróć uwagę, że ponieważ istnieje co najwyżej kilka 1000 tagów, każde wyszukiwanie będzie znacznie szybsze niż zagłębianie się w pełną spis treści.
Wreszcie
Pola CSV to bardzo zły pomysł, nigdy nie używaj ich w bazie danych.
