FULLTEXT-Indizes sind wirklich nicht so schnell, wie Sie vielleicht denken.
Verwenden Sie eine separate Tabelle, um Ihre Tags zu speichern:
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
......
Sie wählen alle Inhalte mit Tag x aus, indem Sie Folgendes verwenden:
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;
Aufgrund des Fremdschlüssels werden alle Felder in tag_links einzeln indiziert.
Das `WHERE tags ='test' wählt 1 (!) Datensatz aus.
Equi-gesellt sich dazu 10.000 Taglinks.
Und Equi verbindet das mit jeweils 1 Inhaltsdatensatz (jeder tag_link zeigt immer nur auf 1 Inhalt).
Aufgrund des Limits von 10 hört MySQL auf zu suchen, sobald es 10 Einträge hat, also schaut es wirklich nur auf 10 tag_links-Datensätze.
Die content.id erhöht sich automatisch, daher sind höhere Zahlen ein sehr schneller Proxy für neuere Artikel.
In diesem Fall nie müssen Sie nach etwas anderem als Gleichheit suchen, und Sie beginnen mit 1 Tag, dem Sie mit Ganzzahlschlüsseln (dem schnellstmöglichen Join) equi-joinen.
Da gibt es kein Wenn-dann-aber, das geht am schnellsten.
Beachten Sie, dass jede Suche viel schneller ist, als das vollständige Inhaltsverzeichnis zu durchsuchen, da es höchstens einige 1000 Tags gibt.
Endlich
CSV-Felder sind eine sehr schlechte Idee, verwenden Sie sie niemals in einer Datenbank.
