Izbor storage enginea u MySQL / MariaDB nije stvar ukusa — mijenja kako se podaci čitaju, pišu, zaključavaju i oporavljaju nakon pada. Evo praktičnog pregleda InnoDB vs MyISAM i zašto je u 2026. InnoDB gotovo uvijek pravi izbor, s par iznimki.

Sažetak razlika

Zašto InnoDB u 99% slučajeva

• Pouzdanost: transaction log (redo log) garantira da nakon iznenadnog pada servera baza zna točno gdje je stala. MyISAM u istoj situaciji ostaje u "corrupted" stanju i zahtijeva ručni REPAIR TABLE.
• Paralelizam: row-level locking znači da dvije konekcije mogu paralelno mijenjati različite retke iste tablice. MyISAM pod opterećenjem serijalizira upise i radi čekanja koja se vide kao "spori web".
• Referencijalni integritet: foreign keys sprečavaju orfanske zapise. MyISAM dopušta da obrišeš roditelja s neregistriranim djecom, pa se problem vidi tek u aplikaciji.
• Kompatibilnost sa CMS-ovima: Craft CMS, Laravel (Eloquent), moderne WordPress instalacije pretpostavljaju InnoDB i koriste transakcije.

Kad MyISAM još može imati smisla

• Read-only log tablice koje se pišu jednom pa dugo čitaju — ali i tu ARCHIVE engine često ima više smisla.
• Legacy sustavi koje ne smijete mijenjati (stari forumi, stari CRM-i). Ako radi — ne dirajte, ali planirajte migraciju.
• Specifični FULLTEXT use-caseovi na MySQL <5.6 — danas nerelevantno.

Kako provjeriti koji engine koriste vaše tablice

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;

Migracija MyISAM → InnoDB

Ne radi se naslijepo. Koraci:

1. Backup cijele baze (mysqldump --single-transaction neće raditi na MyISAM, pa koristi --lock-all-tables).
2. Provjeri indekse: MyISAM nekad dopušta više FULLTEXT indeksa bez InnoDB FULLTEXT ekvivalenta. Planiraj prilagodbu.
3. Provjeri kodiranje i kolaciju: starije MyISAM tablice često su latin1 — prebacuj na utf8mb4 istodobno s migracijom.
4. Izvedi konverziju po tablici:

ALTER TABLE wp_posts ENGINE=InnoDB, ROW_FORMAT=DYNAMIC;

Za veće tablice koristi pt-online-schema-change (Percona Toolkit) da izbjegneš dugi lock.

Nakon migracije

• Provjeri innodb_buffer_pool_size — za InnoDB je to glavna stvar za performanse. Vidi "MySQL optimizacija" uputu za detalje.
• Aktiviraj innodb_file_per_table = 1 tako da svaka tablica bude u vlastitom .ibd fileu — olakšava backup i shrink.
• Pokreni ANALYZE TABLE na migriranim tablicama da se statistike osvježe.

Česte zablude

1. "MyISAM je brži za SELECT": istina samo za bare-metal SELECT COUNT(*) FROM t bez WHERE. Za stvarne aplikacijske upite InnoDB s dovoljno RAM-a je brži ili izjednačen.
2. "InnoDB je težak na disku": .ibd fileovi mogu rasti ali InnoDB kompresija (ROW_FORMAT=COMPRESSED) to rješava za read-heavy tablice.
3. "Dovoljno je samo ALTER TABLE": točno za male tablice, ali veće treba pažljivo kroz online schema change ili u maintenance prozoru.

Ako na hostingu zateknete miješanu bazu (pola MyISAM, pola InnoDB), naša preporuka je uvijek migracija na InnoDB — uz planiranu proceduru, backup i provjeru da aplikacija ne traži nešto MyISAM-specifično (rijetko, ali moguće). Podrška može provesti migraciju i pripremiti statistike prije i poslije.