MyISAM-ból InnoDB-be. Van-e valamilyen funkcionális hátránya?
Sziasztok!
Egy nagyságrendileg 200 táblát tartalmazó - összesen körülbelül 8 millió soros - adatbázisnál át kellene térni végre az InnoDB-re a MyISAM-ról. Okozhat-e ez bármilyen működési problémát?
Azzal tisztában vagyok, hogy a két motor működése jelentősen eltér. De lehet-e hogy valamilyen SQL kérés ami jelenleg lefut, az a váltás után nem fog menni? Úgy gondolom nem, hiszen MySQL szerver kezeli az egészet, és "csak" a tárolás módja változik meg, de azért megnyugtató lenne néhány hozzászólás a nálamnál tapasztaltabbak részéről.
Előre is köszönöm!
■ Egy nagyságrendileg 200 táblát tartalmazó - összesen körülbelül 8 millió soros - adatbázisnál át kellene térni végre az InnoDB-re a MyISAM-ról. Okozhat-e ez bármilyen működési problémát?
Azzal tisztában vagyok, hogy a két motor működése jelentősen eltér. De lehet-e hogy valamilyen SQL kérés ami jelenleg lefut, az a váltás után nem fog menni? Úgy gondolom nem, hiszen MySQL szerver kezeli az egészet, és "csak" a tárolás módja változik meg, de azért megnyugtató lenne néhány hozzászólás a nálamnál tapasztaltabbak részéről.
Előre is köszönöm!
nem lesz gond.. elvileg :)
mentés, teszt, ok
Teszt localban megvolt, eddig nem tapasztaltam problémát.
Némileg lassulni fog a
A keresést segíti
Tranzakció kezelés nélküli adatbázis gyakorlatilag öngyilkosság. Egyedül akkor lehet használni bármire is, ha nincsenek kapcsolt táblák, vagy nincs olyan helyzet, hogy egyszerre több táblát kellene módosítani. Ellenkező esetben inkonzisztens adatok kerülnek fel... Mondjuk ezeket meg lehet időzítetten elleőriztetni, meg törölni, de ez már olyan szintű gányolás, hogy egyszerűen nem éri meg. Egyszer követtem el ilyesmit, többször nem fogok...
Minek?
Kell tranzakciókezelés?
Tudtommal - remélem szól vki, ha tévedek! - más igazán jelentős különbség nincs. Na jó, ott vannak még az idegen kulcsok és a csak rekordszintű zárolás (ami szerintem weben majdnem felesleges), de cserébe lassabb.
Ha nem kell vmi olyat újítanod, amihez InnoDB kell, akkor szerintem kár átvariálni.
Megelőztél, ott a pont.
Nekem úgy tűnik,
Dolgoztam velük
Köszi!
"Régi"
Ettől függetlenül, amit leírnak, az igaz. Én mondjuk nem használnék MyISAM-ot, mert nem felel meg az ACID követelményeinek, legfeljebb nem kritikus adatokat tárolnék ilyen táblákban.
Mondjuk nem véletlen, hogy az
De az az említett full text search bizonyos esetekben jól jöhet, ha jól értem, amit olvastam róla.
És olvasási performanciában még mindig lehagyja a myisam... :-)
Beszúrás, frissítés
INSERT/UPDATEmint aSELECT, akkor sokkal jobb lesz a teljesítmény InnoDB-vel.Ha ennyi a lényeg,
A tranzakciókezelés már érdekesebb.
A cikket (HZ) még csak átfutottam, így elsőre nem úgy tűnik, mintha nagyon rossz lenne a myisam... Inkább csak mindkettő előny / hátrány - felsorolása. Mindegy, majd átrágom, attól bajom nem lesz.
Szerk.: na, átrágtam, amennyire megértettem, igazam volt. Kereséshez sokszor jobb lehet a myisam. Nagyobbacska rekordszámnál főként. Sokszor gyorsabb az innodb, de erőforrásigényesebb is. Szóval nem kell váltani mindenképp.
Az egy szép világ lenne, ha
Nekem spec az a kedvencem, ahol innodb, és nincs fk, meg semmi constraint :)
Ezt kifejtenéd bővebben?
Amíg ő előkerül: gyanítom,
Igen, erre gondoltam.
Hogyne, persze...
De túlsarkítod a dolgot, nincs ekkora minőségi különbség, és sok fontos szolgáltatás meg az innodb-ben nincs meg. Nekem sem a sebessége a legfontosabb, de az is fontos.
Mi az a sok fontos
Akkor szorozd be tízzel, vagy
Én egyébként nem kifejezetten az innodb mellett voksolok (nem is igazán használok mysqlt), hanem a minek tranzakció, meg constraintek a webre, ha a myisam gyorsabb hozzáállás ellen.
És dolgoztam, dolgozok is nagyobb adatbázisokkal, láttam már 1msecnél nagyobb válaszidőt :)
innodb -> myisam csere?!
Pusztán megkérdőjeleztem - meglévő adatbázisnál - a myisam -> innodb csere hasznosságát. Ezt fent is tartom.
De azt sem mondtam, hogy én nem használok innodb-t. Ha kell külső kulcs, tranzakciókezelés (gyakran), akkor kell. Viszont néha még hasznos is tud lenni a tábla szintű zárolás.
A fulltext (jövő) kétségkívül erősen az innodb felé nyomja a mérleg nyelvét, köszönöm Gábor, még nem tudtam.
Szerk.: ja és a sebesség. Való igaz, a (PHP) szkripted sokkal több ideig dolgozik az adatokon, mint amennyi idő alatt megkapja. Csakhogy amíg kapja, addig "vár rá", tehát ez az idő is számít annyiban, hogy hozzáadódik a nagyobb időhöz.
"Ha kell külső kulcs,
Így van. És én erre utaltam, hogy ez a feltétel eléggé elméleti (amennyiben írjuk is az adatbázist, márpedig jellemzően szoktuk), ergo a myisam sebességelőnyével szemben jóval fontosabb ezen feature-ök megléte (tranzakció, fk, row lock). Ezért eléggé indokolt szerintem innodbt használni myisam helyett. Illetve van még egy igen fontos dolog szerintem. Ez pedig az MVCC. Arra gondolok, hogy egy esetleges crash esetén mennyi idő (ha egyáltalán lehet myisam fileokból) helyreállítani egy adatbázist. Ez nem fejlesztői, hanem üzemeltetői kérdés, de jó tisztában lenni ezzel a különbséggel is. Jó nagy adatbázisnál a myisamchk eléggé komoly büntetés is lehet :)
Köszönöm mindenkinek! Ezek
innodb
Ha mégis "fizikailag" törölsz autoincrementált értékű sorokat egy InnoDd táblából, DE ezen oszlop/kulcs alapján kapcsolt táblában viszont nem törlöd a hozzá csatolt sorokat (tehát valójában csak a reláció egyik oldalát törlöd ki), majd a mysql szerver újra lesz indítva (enélkül nem jön elő a hiba!) és az adott (autoincrement-es) táblába újabb adatok kerülnek be az újraindítás után szintén autoincrement-tel, azok a sorok felvehetik a korábban törölt sorok automatikusan kiosztott, de törölt értékeit.
Így nagyon "érdekes" eredményeket fogsz kapni különösebb hibaüzenet nélkül.
Max akkor fog feltűnni és lesz hiba, ha nem 1-sok kapcsolat van a táblák közt, hanem 1-1 kapcsolat, mert elvileg ilyenkor a kapcsolt tábla kulcsa egyedi és így - egy insert + last insert id után - "duplikált sor/ez az érték már létezik" szerű hibaüzenetet fogsz kapni.
--
Nem tudom, hogy a frissebb MySQL-ben ez hogyan van, ebbe kb. 2,5 éve futottam bele és néztem egy igencsak nagyot.
Persze mindig mondják, hogy "fizikálisan" nem szokás törölni sorokat, csak egy flag-gel megjelölni a töröltet.
leírás
Hát ez így nem igaz, ha
Pont ezt írtam fentebb, mint
Biztosabb egy ilyen: http://stackoverflow.com/questions/282099/whats-the-hi-lo-algorithm. Bár phpban ennek kicsit macerásabb a megvalósítása (kell hozzá pl memcached).
De még célszerűbb olyan adatbázist választani, amiben van pl sequence :)
foreign keys
Csak azért írtam le, mert a kérdező a myisam->innodb átállásról kérdezett,
és ha ezt úgy intézi, hogy kiválasztja a másik táblatípust és kész ezzel átállt - akkor akár így is járhat :)