Eksportuj tylko schemat (strukturę) ze zrzutu SQL

Trzy sytuacje wciąż się powtarzają:

• Postaw schemat na potrzeby środowiska staging lub CI — chcesz pustej struktury tabel, aby testy mogły działać na prawdziwych kolumnach, indeksach i ograniczeniach, ale absolutnie nie chcesz przenosić gigabajtów produkcyjnych wierszy do tymczasowego środowiska.
• Tylko dane inicjalizujące (seed) — schemat już istnieje w docelowej bazie danych i potrzebujesz tylko wierszy INSERT, aby ją wypełnić, bez instrukcji CREATE, które kolidowałyby z tym, co już tam jest.
• Pozbądź się szumu — zrzut jest rozdęty przez tabele logs, sessions, audit_trail lub cache z dziesiątkami milionów wierszy, których nigdy nie chcesz importować.

Dlaczego mysqldump --no-data nie wystarczy

Klasyczna porada to mysqldump --no-data (tylko struktura) lub mysqldump --no-create-info (tylko dane). Oba to flagi eksportu: zmieniają to, co zawiera świeży zrzut z działającej bazy danych. Nie robią nic dla zrzutu, który masz już na dysku jako plik .sql.

W praktyce plik często trafia do Ciebie od kogoś innego, z zadania kopii zapasowej lub z serwera, do którego nie masz już dostępu na żywo. Nie możesz ponownie uruchomić mysqldump na bazie danych, która jest nieosiągalna — dane logowania przepadły, serwer został wycofany, albo plik to po prostu wszystko, co dostałeś. W tym momencie flagi są bezużyteczne, a Tobie zostaje edycja samego pliku.

Sposób ręczny

Oczywistym ruchem jest usunięcie wierszy za pomocą grep lub sed. Aby zachować strukturę i usunąć dane:

# zachowaj wszystko oprócz wierszy INSERT
grep -v '^INSERT INTO' dump.sql > schema.sql

# lub zachowaj tylko wiersze INSERT, aby uzyskać plik z samymi danymi
grep '^INSERT INTO' dump.sql > data.sql

Wygląda dobrze na małym, uporządkowanym zrzucie — a potem psuje się na prawdziwym:

• Wielowierszowe INSERTy. Pojedynczy INSERT INTO … VALUES może obejmować tysiące wierszy. grep dopasowuje pierwszy wiersz i zostawia resztę wartości osieroconych, tworząc uszkodzony plik.
• Rozszerzone wstawienia. mysqldump grupuje wiele wierszy w jedną gigantyczną instrukcję. Filtry oparte na wierszach nie potrafią rozpoznać, gdzie taka instrukcja się kończy.
• Komentarze i bloki. Warunkowe bloki /*! … */, LOCK TABLES i komentarze -- przeplatają się z danymi, więc naiwny filtr albo zachowuje śmieci, albo wycina coś, czego potrzebuje import.
• Tylko dane jest jeszcze gorsze. Czyste grep '^INSERT' odrzuca instrukcje SET i LOCK, od których zależą wiersze, a każdy INSERT, który nie zaczyna się dokładnie od kolumny zero, po cichu znika.

Kończysz, debugując własny filtr, zamiast otrzymać swój schemat.

Tylko struktura lub tylko dane za pomocą DumpCleaner

DumpCleaner rozumie instrukcje SQL, zamiast dopasowywać wiersze, więc niezawodnie oddziela strukturę od danych — na plikach dowolnego rozmiaru:

1. Przeciągnij swój zrzut .sql do DumpCleaner (MySQL, MariaDB lub PostgreSQL). Parsuje plik strumieniowo, więc wielogigabajtowy zrzut wczytuje się ze stałym zużyciem pamięci.
2. Przełącz typy instrukcji, które chcesz: CREATE TABLE, CREATE INDEX, INSERT INTO, ALTER, DROP, LOCK, SET. Odznacz INSERT INTO, a otrzymasz samą strukturę; odznacz CREATE TABLE / CREATE INDEX, a otrzymasz same dane.
3. Albo wybierz gotowy zestaw — Tylko struktura lub Tylko dane — aby ustawić wszystkie przełączniki w jednym kroku, a potem dostroić je per tabela, jeśli chcesz.
4. Eksportuj. Otrzymujesz szczupły plik schematu dla stagingu lub CI albo czysty zrzut z samymi danymi do inicjalizacji.

Ponieważ filtr jest świadomy instrukcji, wielowierszowy rozszerzony INSERT jest zachowywany lub usuwany w całości — nigdy nie przecinany w połowie.

Prawdziwa siła polega na tym, że filtrowanie działa per typ instrukcji i per tabela, a te dwa się łączą. Możesz zachować strukturę każdej tabeli, ale dołączyć dane INSERT tylko dla trzech tabel, których naprawdę potrzebujesz — pozostawiając tabelę logs z 89 milionami wierszy jako pustą skorupę. To coś, czego żadna flaga --no-data nie potrafi wyrazić.

Najczęściej zadawane pytania