Izbira shranjevalnega mehanizma v MySQL / MariaDB ni stvar okusa – spreminja način branja, zapisovanja, zaklepanja in obnavljanja podatkov po sesutju. Tukaj je praktični pregled InnoDB v primerjavi z MyISAM in zakaj je InnoDB leta 2026 skoraj vedno prava izbira, z nekaj izjemami.

Povzetek razlik

Zakaj InnoDB v 99 % primerov

• Zanesljivost: dnevnik transakcij (dnevnik ponovitev) zagotavlja, da po nenadnem sesutju strežnika baza podatkov natančno ve, kje je končala. MyISAM v isti situaciji ostane v "poškodovanem" stanju in zahteva ročno REPAIR TABLE .
• Vzporednost: zaklepanje na ravni vrstic pomeni, da lahko dve povezavi vzporedno spreminjata različne vrstice iste tabele. MyISAM serializira zapise pod obremenitvijo in ustvarja čakalne vrste, ki se vidijo kot »počasen splet«.
• Referenčna integriteta: tuji ključi preprečujejo osirotele zapise. MyISAM omogoča brisanje starša z neregistriranimi otroki, zato je težava vidna le v aplikaciji.
• Združljivost s sistemi za upravljanje vsebin (CMS): Craft CMS, Laravel (Eloquent), sodobne namestitve WordPressa predvidevajo InnoDB in uporabljajo transakcije.

Ko je MyISAM še vedno smiseln

• Dnevniške tabele samo za branje, ki se zapišejo enkrat in se berejo dolgo časa – vendar je tudi tukaj pogosto bolj smiseln mehanizem ARCHIVE .
• Zastareli sistemi, ki jih ne smete spreminjati (stari forumi, stari CRM-ji). Če deluje – se ga ne dotikajte, ampak načrtujte migracijo.
• Specifični primeri uporabe FULLTEXT v MySQL <5.6 – danes nepomembni.

Kako preveriti, kateri mehanizem uporabljajo vaše tabele

 SELECT table_schema, table_name, engine FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','mysql','performance_schema','sys') ORDER BY engine, table_schema, table_name;

Selitev MyISAM → InnoDB

To se ne dela na slepo. Koraki:

1. Varnostno kopirajte celotno bazo podatkov ( mysqldump --single-transaction ne bo deloval na MyISAM, zato uporabite --lock-all-tables ).
2. Preverite indekse: MyISAM včasih dovoljuje več indeksov FULLTEXT brez ekvivalenta InnoDB FULLTEXT . Načrtujte prilagoditev.
3. Preverite kodiranje in primerjavo: starejše tabele MyISAM so pogosto latin1 – hkrati z migracijo preklopite na utf8mb4 .
4. Izvedite pretvorbo po tabeli:

 ALTER TABLE wp_posts ENGINE=InnoDB, ROW_FORMAT=DYNAMIC;

Za večje tabele uporabite pt-online-schema-change (Percona Toolkit), da se izognete dolgim zaklepanjem.

Po migraciji

• Preverite innodb_buffer_pool_size – za InnoDB je to velika težava z zmogljivostjo. Za podrobnosti glejte vodnik »Optimizacija MySQL«.
• Omogočite innodb_file_per_table = 1 , tako da je vsaka tabela v svoji datoteki .ibd – to olajša varnostno kopiranje in krčenje.
• Za osvežitev statistike zaženite ukaz ANALYZE TABLE na preseljenih tabelah.

Pogoste zmote

1. "MyISAM je hitrejši za SELECT": drži samo za gole SELECT COUNT(*) FROM t brez WHERE . Za resnične poizvedbe aplikacij je InnoDB z dovolj RAM-a hitrejši ali enako.
2. "InnoDB zaseda veliko prostora na disku": Datoteke .ibd lahko rastejo, vendar stiskanje InnoDB ( ROW_FORMAT=COMPRESSED ) to reši za tabele, ki zahtevajo veliko branja.
3. »Samo ALTER TABLE je dovolj«: velja za majhne tabele, večje pa je treba skrbno spreminjati s spletno spremembo sheme ali v vzdrževalnem oknu.

Če na gostovanju najdete mešano bazo podatkov (pol MyISAM, pol InnoDB), priporočamo, da vedno migrirate na InnoDB – z načrtovanim postopkom, varnostnim kopiranjem in preverjanjem, ali aplikacija išče nekaj specifičnega za MyISAM (redko, vendar mogoče). Podpora lahko izvede migracijo in pripravi statistiko pred in po.