MySQL fulltext priveľa výsledkov a ich zoraďovanie

Mam "mensi" problem s rychlostou mojho fulltextoveho vyhladavaca.

Zjednodusena verzia, kde je vidiet podstatu problemu:



Cele je to spravene obvykle za 0.01s, ale ak vyhladavanemu vyrazu zodpoveda privela riadkov (100000+), to zoradovanie sa predlzi na viac nez 3s napriek tomu ze stlpec id mam indexovany.

zabudol si na order ? om to musi po vybrati este aj zoradit !!!

podľa mňa nezabudol.. akurát len očakáva, že pri 100 000 + výsledkoch to stihne rovnako rýchlo...

To ze je indexovany znamena, ze DB server ma vyskladanu nejaku strukturu (obvykle B+ strom), ale hlbka predsa rastie linearne, takze pochopitelne pri rozhodovani musi robit vela porovnani (vypoctova zlozitost nie je O(1) ale logaritmicka v akomkolvek type suboroveho indexu).

A ako by som to mohol co najefektivnejsie zoradit?

Pokial nema byt ORDER BY v samotnej vyhladacej query, napadlo ma jedine vytvorit CRON s poziadavkou ALTER TABLE ... ORDER BY id DESC, ale to pri robustnejsich db nie je velmi dobry napad.

druha moznost je mat dostatok RAMky aby databaza nemusela data pred zoradovanim swapovat na disk

V MySQL sa da nastavit velkost buffra pre indexy, myslim ze sa to vola key_buffer_size ...

Inak to nie je zrovna banalna zalezitost, fulltextove hladanie je narocne. Potom sa zvykne distribuovat vypoctovy vykon na viac serverov, optimalizovat rozhodovacie stromy dotazov(toto som videl len v Oracle, vyplyva to z ekvivalentnych zapisov niektorych query a parser sa rozhoduje niekde nespravne a da sa ho nutit spravit ine rozhodnutie - cestra v strome ...), popr. zvacsit pocet vlakien ktore obsluhuju indexy (znova neviem ako a ci sa to da v MySQL) ...

Najjednoduchsie (a casto aj najlacnejsie) riesenie je hruba sila (silnejsie zelezo), pokial to teste ma zmysel.

Rozumiem.

vykon++ => rychlost++

aaa je lepsie zoradovat to v kazdej query alebo pouzivat CRON??

Ak to dobre chapem, tak ty sa snazis tym cronom v intervaloch usporiadavat tabulku.
To tak ale nefunguje

Data su v tabulke "nahadzane". Ked nie je nad tabulkou index tak sa sekvencne prehladavaju bloky. Ak je nad nou index, tak to je struktura ulozena v pamati (ok nody su uz adresy na disku), ktora ukazuje kam sa mas pozerat pri hladani kluca (podla ktoreho je to indexovane).

Navyse alter table meni schemu tabulky, nie jej data.

To ze spravis order by uz spravis nad selectnutymi datami, nema to nic s tym, ako budu data vyzerat v tabulke.

Snazim sa tie data nejakym sposobom zoradit a nejako sa nemozem zmierit s tym, ze je to take narocne pre zelezo. Pride mi zvlastne, ze vyhladane same o sebe je to za necelu stotinu sekundy a zoraduje sa to potom niekolko sekund. Mam pocit, ze som tam niekde spravil chybu, neviem ako to optimalizovat.