Când instalați MySQL sau MariaDB, motorul de stocare implicit pentru tabelele noi este InnoDB, iar înțelegerea fișierelor pe care le scrie pe disc este primul pas către un administrator care poate diagnostica probleme reale de producție, nu doar rula comenzi din tutoriale. Directorul de date, de regulă /var/lib/mysql pe Ubuntu 24.04 sau AlmaLinux 9, conține mai multe categorii de fișiere InnoDB, fiecare cu un rol distinct.
Fișierul ibdata1 și tablespace-ul de sistem
Fișierul ibdata1 reprezintă tablespace-ul de sistem și, în configurațiile mai vechi fără innodb_file_per_table, conținea efectiv toate tabelele InnoDB din instanță. Astăzi, chiar și cu tablespace separat per tabelă, ibdata1 tot stochează dicționarul de date intern, undo log-urile în unele versiuni și buffer-ul de tip doublewrite dacă nu ați activat fișierul separat pentru el. Un ibdata1 care crește necontrolat, uneori la zeci de gigabytes pe un server cu baze de date mici, este un semn clasic că lipsea innodb_file_per_table la crearea tabelelor, iar remedierea presupune un export și o reimportare completă a datelor, nu doar o schimbare de parametru.
Tablespace per tabelă și fișierele .ibd
Cu innodb_file_per_table=ON, valoare implicită atât în MySQL 8, cât și în MariaDB 10.6 și versiunile ulterioare, fiecare tabelă primește propriul fișier cu extensia .ibd, situat în directorul bazei de date respective. Această separare aduce două avantaje practice pe care le veți folosi frecvent: puteți elibera spațiu pe disc cu OPTIMIZE TABLE fără să afectați alte tabele, și puteți muta sau copia o singură tabelă cu mecanismul de transportable tablespace, prin ALTER TABLE ... DISCARD TABLESPACE urmat de IMPORT TABLESPACE pe destinație.
Fișierele ib_logfile și jurnalul redo
Fișierele ib_logfile0 și ib_logfile1, redenumite în MySQL 8.0.30 și versiunile ulterioare în directorul #innodb_redo cu mai multe fișiere numerotate, formează jurnalul redo circular. Dimensiunea lor totală este controlată de innodb_redo_log_capacity în MySQL recent, respectiv de innodb_log_file_size înmulțit cu innodb_log_files_in_group în versiunile mai vechi și în MariaDB. Un jurnal redo prea mic forțează scrieri frecvente pe disc și limitează performanța la inserții masive, subiect pe care îl veți relua în capitolul despre tuning.
Verificare practică
Pentru a vedea structura reală pe serverul dumneavoastră, rulați:
ls -lh /var/lib/mysql/*.ibd 2>/dev/null | head
du -sh /var/lib/mysql/ibdata1
mysql -e "SHOW VARIABLES LIKE 'innodb_file_per_table';"Pe un server de găzduire cu cPanel și LiteSpeed, unde spațiul de disc este adesea limitat la un plan cu SSD partajat, un ibdata1 de dimensiuni mari, provenit dintr-o instalare veche fără tablespace per tabelă, este una dintre cauzele frecvente pentru care clienții rămân fără spațiu chiar dacă bazele de date individuale par mici.
Greșeală frecventă
Ștergerea directă a fișierelor .ibd sau a lui ibdata1 în timp ce serviciul MySQL rulează duce la corupție ireversibilă a instanței. Orice modificare de structură a tablespace-urilor se face exclusiv prin comenzi SQL sau cu serviciul oprit, niciodată prin manipulare directă a fișierelor pe un server activ.