XtraDB a indexy

Mám starou db v myisam - tzn. nepouzivaji se transakce, foreign keys a podobně Jedná se o statistiky, tabulky mají stejnou strukturu: 27 sloupců, 1 primární index a 11 dalších indexů který sou zvolený podle toho jak se nejvíc provádí selecty s where, group a order Používá se mariadb, udělal sem update na nejnovější 10.0.7 kde xtradb defaultně nahrazuje innodb. Na xtradb bych chtěl přejít kvůli row-level locku. Zkusil sem udělat pár testů na jedné tabulce s 6M řádkama a moc se mi to nezdá: využití disku (data+index) - myisam (513MiB+402MiB), innodb (822Mib+1189MiB) innodb(xtradb) by takto zabíralo víc než dvojnásobek místa oproti myisam což mi přijde hrozně moc. zkusil sem teda další test a udělal větší select s hodně where, group a order z této velké tabulky na xtradb a trval 63s, potom sem zkusil odmazat všechny indexy a nechal jen primární kterej je jen auto-increment id řádku a najednou select trval 21s. mám to chápat tak, že u xtradb v případě že nepoužívám transakce, na těchto tabulkách nejsou joiny atd - jen základí operace tak mi stačí primární index a všechny ostatní sou zbytečný? celý mi to přijde jako blbost ale ty výsledky sou zajimavý. myslíte že je dobrej nápad zkusit v produkčním prostředí kde je kolem 100k visitorů online pustit alter table postupně na všechny tabulky a dropnout všechny indexy kromě primárního? je jasný, že to potrvá několik hodin a to ani nemluvím o tom kdyby se pak situace zhoršila a museli se indexy znova vytvářet a vracet to zpátky, to už by bylo na několik dní...(celkově se jedná asi o 150GB dat)

Experimentovat v produkčním prostředí není nikdy dobrý nápad.Použil bych zálohu DB, obnovil ji někde vedle na čistém stroji (ideálně virtuálka, aby to nemělo tak vysoký výkon a vše se ihned projevovalo) a začal testovat/experimentovat. U virtuálky si můžeš dělat průběžně snapshoty, zálohy a detailně si to proměřit

To vím, bohužel ale nemám železo na který bych dal zálohu a nasimuloval tam reálnej provoz takže musím zjistit co nejvíc info a pak ten přechod provést co nejšetrněji za provozu. Je vůbec možný aby se to takto chovalo? Že by primární index na xtradb tabulce bez transakcí zastal funkci všech ostatních a ty byly zbytečný a naopak to zpomalili? Přijde mi to jako blbost ale ten test na jedné tabulce je fakt zvláštní.

Divné to je v každém případě - nebyl už ten dotaz nacachovaný z předchozího pokusu?

z cache by to mělo jít v rámci milisekund a mezi pokusama sem počkal docela dost dlouho a dal ještě znova alter table takže by to cache být neměla

Neviem kolko maz vyhradenej ramky pra cache. Ako tu bolo spomenute, mohol ti ten prvy select potrebne data nacachovat z disku do ramky, a potom mohlo to druhe spustenie ist rychlejsie. Nezda sa mi, zeby pokial su rozumne navrhnute indexy a select ich dokaze vyuzit bol full scann tabulky rychlejsi ako pristup cez indexy. Vsetko zavisi od struktury tabuliek, ake indexy tam maz a ake selecty nad tymi tabulkami vykonavad. Ja neviem, ale to mnozstvo co ti zaberaju indexy je nejake obrovske. Neviem ci ti MySQL dokaze dat nejaku statistiku vyuzitia indexov. Mozno tam maz kopu zbytocnych indexov, ktore sa nevyuzivaju. Skusal si si urobit statistiku najpouzivanejsich prikazov a potom tieto prikazy prehnat cez nejeky SQL profiler. Mozno zistis, ze maz indexy ktore vobec nevyuzivas.ak mozes hod create table pre tabulku vratane indexov a napr ten select ktory ti siel rychlo bez indexov a pomaly z indexami a popripade kolko zaznamov tam maz.