MySQL Full Text Search

Astăzi am jucat pentru a optimiza un proces lent SQL Aplicarea genul

SELECT * FROM 'table' WHERE `field` LIKE '%word%'

În cazul în care este problema acum aici – ultima parte "% cuvânt%’ și în chiar mai multe caractere specifice % înainte de cuvântul, care fac. simbolul wildcard % ,înainte de orice valoare, face în mod direct ne interoga direct în lent, deoarece în acest fel aplicația ne împiedică să utilizeze indici de câmp. Deciziile ca întotdeauna, dar nu întotdeauna clar 😆 global MySQL Ei au o soluție la această problemă căutare fulltext câmp de indexare. Cum se schimbă terenul are o mulțime de documente scrise, dar graba va descrie modul de a schimba cererea de top, pentru că vom ajunge la o mică dramă în cele din urmă. Sledka ca domeniu fulltext de mai sus se aplică, cerere trebuie să fie modificări ale tipului de:

SELECT * FROM `table` WHERE MATCH (field) AGAINST ('word')

Prin urmare, structura este evidentă și are nevoie de nici o discuție inutilă. Interogarea de mai sus va intra în vigoare, în cazul în care cuvântul, pentru a face o solicitare de cel puțin 4 simboluri, Valoarea implicită este, dacă doriți să modificați trebuie să specificați valoarea, която желаете в my.cnf в частта [mysqld] declarație ft_min_word_len= 3 sau 2, 1 не е добър избор очевидно 😉 . După ce schimbați valoarea și mysql repornire server o necesitate de a face reparații în tabelele, pentru ca noua indexare intră în vigoare. Până în prezent, totul clar: a face modificări, restabili, rebildvam indici și de a face cerere și se întoarce meu 0 Verificare cu ordinul 😀

SHOW VARIABLES

Eu văd că valorile, M-am întrebat în vigoare, rebildvam din nou indexurile – același rezultat. 🙄 neplăcut, foarte inconfortabil. De aici încolo a început un blestemelor mare și zgâriere cheia vărsat 😀, care a fost destul de, destul de interesant. în ansamblu, Am început să citesc documentație nu știu ce drum și a ajuns la un pasaj interesant

Such a technique works best with large collections (de fapt, a fost reglat cu atenție acest mod). Pentru tabelele foarte mici, distribuție cuvânt nu reflectă în mod adecvat valoarea lor semantică, iar acest model poate produce uneori rezultate bizare. De exemplu, deși cuvântul "MySQL" este prezent în fiecare rând din tabelul de articole prezentat mai devreme, o căutare pentru cuvântul produce nici un rezultat

ГРЕДА 😳 Дам табличката ми беше малка – Cu toate acestea, a fost un test de. Aplicația noastră într-un tabel mare peste 2 000 000 ordine și acolo lucrurile au dormit. Ei bine, problema acum clar. Pentru a lua o decizie clară, Voi menționa pe scurt, care acceptă căutarea full text 3 modul avansat BOOLEAN , EXPRESII și LIMBA NATURAL ca ultima lucrare implicit. Pentru moduri pot verifica documentație, Voi explica 2-3 Cuvintele BOOLEAN, deoarece este cheia. Ea susține operatorii logici astfel ȘI, SAU , NU și așa mai departe și se pot face unele magie cu expresii populare, au una, nici o alta, etc.. Se menține și simboluri *, care este echivalent cu un simbol joker % Este util 😉, în cazul în care termenul de căutare este mai mică decât lungimea ft_min_word_len sau tăvi mici ;). Cel puțin pentru mine o masă cu privire la 100 comanda face treaba perfecta. Lăsând numai a se vedea și completat cerere:

SELECT * FROM `table` WHERE MATCH (field)
AGAINST ('*word*' IN BOOLEAN MODE)

Aici vine momentul dacă indexarea funcționează cu caractere wildcard – răspunsul este că nu știu. Принципно мисля, че да, защото не е казано друго в документацията, но в документацията очевидно не се казват или показват много неща 😀

Consolidată prin Zemanta

2 comments

    1. Е при големи таблици вече има други решения 😉 partitions да речем или други механизмни за fulltext search като Sphinx

lasa un raspuns

Adresa ta de email nu va fi publicat. Câmpurile necesare sunt marcate *

Anti SPAM *