Dotaz: Jak zaindexovat správně sloupec kde se vyhledává pomocí like

[urui]

Ahoj. Mám v mysql tabulce sloupec uzivatel. Tabulka bude obsahovat skoro milion záznamů. Zatím to mám udělané tak, že uzivatel je PK a nic víc. Má smysl na takový sloupec aplikovat fulltext index - nepřidělal bych si tím spíše problémy např. 50proc. práh apod. ? Jde o to, abych mohl pomocí selectu nad tabulkou typu ... where uzivatel like '%da_da_' apod. vybrat řádky co nejrychleji. Příp. jak to ještě zrychlit?

Odpovědi

[Heron]

Ta tabulka bude obsahovat milion různých uživatelů? Copak to je za systém?

Fulltext určitě ne, tím si nepomůžeš a už vůbec ne na vyhledávání userů, kde leze počítat v podstatě s náhodným stringem. Tam se uplatní klasický index. Jinak prefixové vyhledávání (to '%da_da_'), bude bez indexu a bude to vždy table scan.

[urui]

Ta tabulka bude obsahovat milion různých uživatelů? Copak to je za systém?

Takový statistický PokusSoft. (Uzivatelska jmena jsou generovana nahodne)

[Ivan]

Pokud bys' o to hodne stal, tak bys' moh implementovat neco jako TRIE. Do druhy tabulky si ulozis pro kazdy userid vsechny rotace(suffixy) userid plus rowid z prvni tabulky. Pak muzes vyhledavat pres index v ty druhy tabuli. Tzn. pri uid 8 znaku a pul milionu uzivatelu budes mit pomocnou tabulku s 4mil radek.

[GeoRW]

query s "like '%da_da_' " ti cez index nepojde; klasicky B-tree index funguje ako strom a ked mas % na zaciatku, tak sa nema o co zachytit; fulltext index funguje na slova a pouziva sa pre polia typu TEXT, kde mas ulozene cele vety/clanky, namatchuje ti to iba cele slova nie casti slov; pre pripad, kde je (iba) na zaciatku % sa da este pouzit revers index, ale query s % na zaciatku sa radsej vyhni vzdy to pojde cez fullscan; v pripade, ze sa nemozes full scanu nijako vyhnut, mozes este tu tabulku rozdelit na particie; neviem ako v MySQL, ale po particiach by to potom malo hladat paralelne ak pouzijes lokalne indexy

[GeoRW]

po particiach by to potom malo hladat paralelne ak pouzijes lokalne indexy

teda samozrejme, by to malo ist paralelne aj ked tam indexy nemas, kedze to cez indexy ani nepojde

[kuka]

Mysql neznam, ale pocitam, ze provest paralelne fullscan by mela umet i bez patitions, pokud to umi s partitions. Pokud by ta tabulka obsahovala dalsi data nezanedbatelne velikosti (napriklad jmeno a prijmeni), ma smysl uvazovat o vytazeni (klidne redundantnim) username do samostatne tabulky, aby fullscan prochazel co nejmensi objem na disku - to muze predstavovat dramaticke zrychleni. Po urceni konkretnich matchujicich zaznamu se pak do hlavni tabulky uz muze pristupovat pres index.

[AraxoN]

Teoreticky by "LIKE '%blabla'" mohlo ísť, ak by cez REVERSE() otočil reťazec a mal nad tým vytvorený funkcionálny index, alebo osobitný pomocný stĺpec, kde by to mal takto otočené.

Potom by robil query takto:

... WHERE reverse_stlpec LIKE REVERSE('%blabla')

Ale v jeho prípade by sa síce zbavil percenta na začiatku, ale mal by tam miesto toho zase podčiarnik. Full scanu by sa aj tak nevyhol.

[FooBar]

Nevim jak je to realne implementovany, obzvlast v MySQL, ale pokud je na zacatku match na "libovolne jedno pismeno", FTS se nemusi provadet, akorat se projde znacne vetsi cast toho indexu (orez prohledavanyho stavovyho prostoru zacne vyrazne pozdejc).

[Josef Kufner]

Vyhni se LIKE s % na začátku. Pokud to nejde, pomoz tomu vyhledávání omezením velikosti prohledávaných dat. Třeba přidáním další podmínky, která už využije index, nebo, pokud jsou si dotazy velmi podobné, připrav si nějaká pomocná data, která vyhledávání urychlí – například prohledávaný text pozpátku, statistiky počtu písmen a podobně.

[FooBar]

Krom toho, co tu bylo zmineno, je pomerne bezny reseni dvojity filtrovani.

Prvni filtrovani je aproximativni, zalozeny napr. na porovnavani Ngramu v textu. To ti muze prinest hromadu false positives, ale vracena podmnozina bude typicky mensi, a z ni uz muzes exaktne filtrovat linearne bez vetsich problemu. Samozrejme, nefunguje to na velmi kratke vyhledavani jako napr. "%f%". Dalsi problem je implementacni, ponevadz netusim jak to realizovat na MySQL...