De ce dimensiunea bazei de date SQL este diferită după exportarea într-un fișier decât pe server?

Atunci când administrați un site web sau o aplicație pe mybox, descărcarea unei copii de rezervă a bazei de date dezvăluie adesea o ciudățenie tehnică derutantă: fișierul .sql descărcat este semnificativ mai mic decât dimensiunea bazei de date afișată în panoul de găzduire, chiar dacă nu l-ați comprimat într-un fișier .zip sau .gz.

Această diferență este absolut normală și reprezintă o realitate operațională fundamentală legată de modul în care sistemele de gestionare a bazelor de date relaționale (RDBMS), precum MySQL sau MariaDB, stochează datele în timp real pe un server, comparativ cu modul în care le reprezintă într-un fișier.

1. Spațiu suplimentar și spațiu liber alocat (spațiu neutilizat)

Bazele de date active sunt concepute pentru viteză, ceea ce înseamnă că acordă prioritate inserării rapide a datelor în detrimentul economisirii stricte a spațiului.

• Realitatea serverului: Când datele sunt șterse sau modificate pe serverul dvs. mybox, sistemul de baze de date nu micșorează instantaneu fișierul fizic de pe disc (acest lucru consumă foarte multe resurse). În schimb, lasă acei sectoare goi, creând “găuri” sau spațiu liber nealocat, marcat pentru operațiuni viitoare de scriere.
• Realitatea exportului: Când declanșați un export (o copiere a bazei de date), sistemul citește doar rândurile de date active. Spațiile goale, prealocate, și suprasarcina internă sunt eliminate, reducând instantaneu dimensiunea fișierului.

2. Reprezentarea binară vs. reprezentarea în text simplu

Formatul unei baze de date active este radical diferit de cel al unui script de rezervă.

• Stocare binară (pe server): Pe serverul dvs., datele sunt scrise într-un format binar extrem de complex (cum ar fi fișierele InnoDB .ibd). Acesta include structura paginilor, spațiile de tabel ale sistemului, ID-urile de urmărire a rândurilor și jurnalele de tranzacții.
• Script text (fișier exportat): Un fișier .sql este doar un fișier text simplu, plat. Acesta conține comenzi sub formă de șiruri de caractere lizibile de către om, precum CREATE TABLE și INSERT INTO. Acesta elimină complet învelișurile binare grele de stocare.

3. Indexurile sunt structurate, nu stocate

Indexurile sunt o necesitate tehnică pentru menținerea vitezei interogărilor de căutare, dar ocupă mult spațiu.

• Pe server: Indexurile sunt arbori binari brute, complet compilați, stocați în cache pe disc pentru a indica unde se află datele. În cazul tabelelor complexe ale aplicațiilor, indexurile pot ocupa cu ușurință 30–50% din spațiul total al serverului.
• În fișierul exportat: Instrumentul de export nu salvează harta structurală a indexului. În schimb, scrie o singură linie de text care detaliază modul de reconstruire a acestuia: SQLALTER TABLE `wp_posts` ADD KEY `type_status_date` (`post_type`,`post_status`,`post_date`,`ID`); Când veți importa în cele din urmă acest fișier într-o nouă bază de date, serverul va citi acea singură linie de instrucțiuni și va construi indexurile voluminoase de la zero.

Matrice de comparație