sql >> Database teknologi >  >> RDS >> Mysql

Bedste måde at gemme tags for hastighed i en enorm tabel

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.




  1. MySQL-sætning for at vælge den seneste indgang i en specifik kolonne

  2. Aggreger bitvis-ELLER i en underforespørgsel

  3. Forhindre flere samme bruger-login på en desktopapplikation

  4. Mysql masseopdatering