MySQL full text search

Vandaag speelde ik tot een langzame optimaliseren SQL Toepassing van het geslacht

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

Waar is het probleem nu hier – het laatste deel '% word%’ en in nog specifiekere tekens % voor het woord, die wel. wildcard symbool % ,voordat enige waarde, direct maakt ons direct zoekopdracht in slow, want op deze manier de toepassing ons stopt om indices gebruik in het veld. Beslissingen zoals altijd, maar niet altijd duidelijk 😆 Overall MySQL Ze hebben een oplossing voor dit probleem fulltext zoeken indexering veld. Hoe werkt het veld veranderende heeft veel schriftelijke documentatie, maar haast zal beschrijven hoe u de top verzoek veranderen, omdat we eindelijk krijgt om een ​​beetje drama. Sledka zoals van toepassing fulltext veld boven, aanvraag moet veranderingen in het type:

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

Zodat de structuur duidelijk en behoeft geen onnodige discussie. De bovenstaande vraag zal in werking treden, als het woord, voor u een verzoek op zijn minst 4 symbolen, De standaardwaarde is, Als u wilt wijzigen moet de waarde op te geven, която желаете в my.cnf в частта [mysqld] verklaring ft_min_word_len= 3 of 2, 1 не е добър избор очевидно 😉 . Nadat u de waarde en de herstart mysql server-een behoefte om herstellingen uit te voeren op uw tafels te veranderen, Om de nieuwe indexering in werking treden. Tot nu toe alles duidelijk: wijzigingen aanbrengen, resetten, rebildvam indexen en doe mijn verzoek en keert terug 0 Controle met de bestelling 😀

SHOW VARIABLES

Ik zie dat de waarden, Ik heb in werking gesteld, rebildvam weer indexen – hetzelfde resultaat. onaangename 🙄, erg ongemakkelijk. Vanaf hier op het begon een grote vervloeking en krassen op de sleutel van de schuur 😀 die vrij was, behoorlijk interessant. over het geheel genomen, Ik begon te lezen documentatie weet niet welke weg en kwam tot een interessante passage

Such a technique works best with large collections (eigenlijk, Het werd zorgvuldig afgestemd op deze manier). Voor zeer kleine tafels, woord distributie houdt onvoldoende rekening met hun semantische waarde, en dit model kan produceren soms bizarre resultaten. Bijvoorbeeld, hoewel het woord "MySQL" is aanwezig in elke rij van de tabel artikelen eerder getoond, een zoektocht naar het woord geeft geen resultaten

ГРЕДА 😳 Дам табличката ми беше малка – Toch was een test. Onze applicatie in een grote tafel over 2 000 000 orde en er dingen sliepen. Nou nu duidelijk probleem. Om duidelijk te beslissing te nemen, Ik zal kort ingaan op, dat ondersteunt full text search 3 geavanceerde modus BOOLEAN , UITDRUKKINGEN en Natural Language als het laatste werk van standaard. Voor modi kunnen documentatie controleren, Ik zal u uitleggen 2-3 BOOLEAN woorden want het is de sleutel. Het ondersteunt logische operatoren zoals AND, OF , NOT en ga zo maar door en kan wat magie met populaire zinnen maken, hebben één, geen andere etc.. Onderhouden en symbolen *, wat overeenkomt met een wildcard symbool % Het is nuttig 😉, wanneer de zoekterm is dan de lengte van ft_min_word_len of kleine bakjes ;). Althans voor mij een tafel met ongeveer 100 Om doet perfecte baan. Waardoor alleen zien en voltooide aanvraag:

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

Hier komt het moment of onze indexering werkt met jokertekens – het antwoord is weet ik niet. Принципно мисля, че да, защото не е казано друго в документацията, но в документацията очевидно не се казват или показват много неща 😀

Versterkt door Zemanta

2 comments

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

Laat een antwoord achter

Uw e-mailadres zal niet worden gepubliceerd. Verplichte velden zijn gemarkeerd *

Anti SPAM *