Експорт само на схемата (структурата) от SQL дъмп

Три ситуации възникват постоянно:

• Създаване на схема за staging или CI — искате празната структура на таблиците, за да могат тестовете да работят срещу реални колони, индекси и ограничения, но в никакъв случай не искате да изпращате гигабайти продукционни редове в среда за еднократна употреба.
• Само начални данни — схемата вече съществува в целевата база данни и просто ви трябват INSERT редовете, за да я попълните, без CREATE заявки, които биха се сблъскали с наличното.
• Отърваване от шума — дъмпът е раздут от таблици logs, sessions, audit_trail или cache с десетки милиони редове, които никога не искате да импортирате.

Защо mysqldump --no-data не е достатъчно

Класическият съвет е mysqldump --no-data (само структура) или mysqldump --no-create-info (само данни). И двете са флагове за експорт: те променят какво съдържа нов дъмп от работеща база данни. Те не правят нищо за дъмп, който вече имате на диска като .sql файл.

На практика файлът често идва от някой друг, от задача за резервно копие или от сървър, до който вече нямате жив достъп. Не можете да пуснете отново mysqldump срещу база данни, която не е достъпна — данните за достъп ги няма, сървърът е изведен от експлоатация или файлът е просто всичко, което са ви подали. В този момент флаговете са безполезни и ви остава да редактирате самия файл.

Ръчният начин

Очевидният ход е да премахнете редове с grep или sed. За да запазите структурата и да махнете данните:

# запази всичко освен INSERT редовете
grep -v '^INSERT INTO' dump.sql > schema.sql

# или запази само INSERT редовете за файл само с данни
grep '^INSERT INTO' dump.sql > data.sql

Това изглежда добре на малък, подреден дъмп — и после се проваля на истински:

• Многоредови INSERT заявки. Една единствена INSERT INTO … VALUES може да се простира на хиляди редове. grep съвпада с първия ред и оставя останалите стойности осиротели, произвеждайки повреден файл.
• Разширени вмъквания. mysqldump групира много редове в една гигантска заявка. Филтрите, базирани на редове, не могат да разберат къде завършва такава заявка.
• Коментари и блокове. Условните блокове /*! … */, LOCK TABLES и коментарите -- се преплитат с данните, така че наивен филтър или запазва боклук, или отрязва нещо, което импортът изисква.
• Само данни е по-лошо. Чист grep '^INSERT' изхвърля SET и LOCK заявките, от които редовете зависят, а всяка INSERT заявка, която не започва точно от колона нула, мълчаливо изчезва.

Накрая дебъгвате собствения си филтър, вместо да получите схемата си.

Само структура или само данни с DumpCleaner

DumpCleaner разбира SQL заявките, вместо да съвпада с редове, така че разделя структурата от данните надеждно — на файлове с всякакъв размер:

1. Плъзнете вашия .sql дъмп в DumpCleaner (MySQL, MariaDB или PostgreSQL). Той парсва файла поточно, така че многогигабайтов дъмп се зарежда с постоянна памет.
2. Превключете типовете заявки, които искате: CREATE TABLE, CREATE INDEX, INSERT INTO, ALTER, DROP, LOCK, SET. Махнете отметката от INSERT INTO и получавате само структура; махнете отметката от CREATE TABLE / CREATE INDEX и получавате само данни.
3. Или изберете предварителна настройка — Само структура или Само данни — за да зададете всеки превключвател на една стъпка, след което прецизирайте по таблица, ако желаете.
4. Експортирайте. Получавате лек файл със схема за staging или CI, или чист дъмп само с данни за начално попълване.

Тъй като филтърът е съобразен със заявките, многоредова разширена INSERT заявка се запазва или премахва като цяло — никога не е прерязана по средата.

Истинската сила е, че филтрирането работи по тип заявка и по таблица, и двете се комбинират. Можете да запазите структурата на всяка таблица, но да включите INSERT данни само за трите таблици, които действително ви трябват — оставяйки таблицата logs от 89 милиона реда като празна обвивка. Това е нещо, което никой флаг --no-data не може да изрази.

Често задавани въпроси