Розділювач Dump SQL
Розбийте великий dump .sql на менші файли на безпечних межах операторів, зберігаючи схему, дані та обмеження у завантажуваному порядку.
🔒 Цей інструмент працює повністю у вашому браузері. Ваші файли ніколи не завантажуються на сервер.
Оберіть файл .sql (.sql.gz теж підходить). Він зчитується локально і ніколи не завантажується на сервер.
Один великий оператор може перевищити цей цільовий розмір, щоб залишитися коректним.
Як працює SQL Dump Splitter
- Додайте файл дампу - звичайний .sql або стиснутий .sql.gz обидва підходять, і він зчитується прямо на сторінці, тож нічого не завантажується на сервер.
- Оберіть розмір фрагмента, який прийме ваш інструмент імпорту або обмеження хостингу.
- Завантажуйте файли за порядком номерів. Розділювач зберігає початковий порядок операторів дампу і залишає будь-яку збережену процедуру, тригер чи функцію незмінною, тому перед імпортом перевірте розділи схеми, даних і обмежень.
FAQ
Чому обмеження мають завантажуватися останніми?
Тому що файли даних посилаються один на одного. Завантаження зовнішніх ключів до появи пов'язаних рядків завершиться помилкою, тому стандартний порядок - схема, потім дані, потім обмеження та індекси.
Чи можна ділити файл у будь-якому місці?
Ні - розбиття посеред оператора створює файли, кожен з яких окремо є некоректним SQL. Розбиття має відбуватися на межах операторів, тому наївне розбиття за кількістю рядків зазвичай ламає файл.
Чи обробляє він збережені процедури, тригери та функції?
Так. Дамп, який змінює роздільник операторів за допомогою DELIMITER ;; для визначення процедури, зберігається як один неподільний блок від відкриваючого рядка DELIMITER до закриваючого, тому межа фрагмента ніколи не потрапить усередину тіла процедури або між DELIMITER ;; та залежним від нього тілом.
Чи можна використовувати стиснутий дамп .sql.gz?
Так - просто додайте файл .gz напряму, і він буде розпакований у вашому браузері перед розбиттям, з використанням того самого стандартного формату gzip, який створюють команда gzip та mysqldump | gzip. Нічого не завантажується і не конвертується на сервері.
Чому імпорт досі повільний після розбиття?
Розбиття вирішує проблему обмежень розміру, а не швидкості. Для швидкості завантажуйте дані до створення індексів і обгортайте пакети в транзакції.
Чи працює це лише з дампами MySQL?
Ні. Розбиття відбувається універсально за крапками з комою, що завершують оператори, тому дамп PostgreSQL чи інший SQL теж розбивається безпечно. Специфічна для MySQL обробка DELIMITER активується лише тоді, коли дамп справді використовує цей синтаксис для збережених процедур або тригерів - в інших випадках вона не виконує жодних дій.
Як обрати розмір фрагмента?
Орієнтуйтеся на те, що відхиляє весь файл цілком - phpMyAdmin і багато хостингів обмежують завантаження від кількох МБ до кількох сотень МБ, тож дізнайтеся цей ліміт і оберіть розмір фрагмента із запасом нижче нього. Менші фрагменти означають лише більше файлів для імпорту за порядком, жодних інших недоліків немає.
Порівняння
| Функція | Online Tool Store | CLI-скрипт | Плагін IDE |
|---|---|---|---|
| Безпечні для операторів межі | ✓ | ✗ | ✓ |
| Зберігає початковий порядок операторів | ✓ | ✗ | Іноді |
| Дамп не завантажується на сервер | ✓ | ✓ | ✗ |
| Працює при перевищенні ліміту завантаження хостингу | ✓ | Залежить | ✗ |
| Зберігає збережені процедури/тригери незмінними при зміні DELIMITER | ✓ | Лише якщо скрипт враховує DELIMITER | ✓ |
| Приймає стиснутий дамп .sql.gz напряму | ✓ | Підтверджено на sqlsplit.com; звичайному скрипту зазвичай спершу потрібно розпакувати файл | ✓ |
SQL Dump Splitter допомагає, коли імпорт не проходить через розмір файлу - він розбиває там, де це дозволяє SQL, розпаковує стиснутий дамп за вас і зберігає кожен фрагмент безпечним для операторів, включно зі збереженими процедурами.