Online Tool Store
SQL Dump Splitter
Breek een grote .sql dump in kleinere bestanden op veilige statement-grenzen, houdend schema, gegevens en constraints in laadbare volgorde.
🔒 Deze tool werkt volledig in je browser. Je bestanden worden nooit naar een server geüpload.
Kies een .sql-bestand (.sql.gz werkt ook). Het wordt lokaal gelezen en nooit geupload.
Een groot enkel statement kan dit streefdoel overschrijden om geldig te blijven.
Hoe SQL Dump Splitter werkt
- Voeg het dumpbestand toe - een gewoon .sql-bestand of een gecomprimeerd .sql.gz-bestand werken beide, en het wordt op de pagina gelezen, dus er wordt niets geupload.
- Kies een chunkgrootte die je importtool of hostinglimiet kan verwerken.
- Laad de bestanden in numerieke volgorde. De splitter behoudt de oorspronkelijke volgorde van de statements in de dump en houdt elke stored procedure, trigger of functie intact, dus controleer de schema-, data- en constraint-secties voordat je importeert.
FAQ
Waarom moeten constraints als laatste worden geladen?
Omdat databestanden naar elkaar verwijzen. Het laden van foreign keys voordat de rijen waarnaar ze verwijzen bestaan, mislukt, dus de standaardvolgorde is schema, dan data, dan constraints en indexen.
Kan ik overal in het bestand splitsen?
Nee - splitsen midden in een statement levert bestanden op die afzonderlijk ongeldige SQL zijn. Splitsingen moeten op statementgrenzen liggen, waardoor een simpele splitsing op regelaantal meestal mislukt.
Ondersteunt het stored procedures, triggers en functies?
Ja. Een dump die het statement-scheidingsteken wijzigt met DELIMITER ;; om een routine te definieren, wordt behandeld als een ondeelbaar blok van de openende DELIMITER-regel tot de sluitende, zodat een chunkgrens nooit binnen een procedure-body terechtkomt of tussen DELIMITER ;; en de body die ervan afhangt.
Kan ik een gecomprimeerde .sql.gz-dump gebruiken?
Ja - zet het .gz-bestand er direct in en het wordt in je browser gedecomprimeerd voordat het gesplitst wordt, met hetzelfde standaard gzip-formaat dat het gzip-commando en mysqldump | gzip produceren. Er wordt niets geupload of server-side geconverteerd.
Waarom is mijn import na het splitsen nog steeds traag?
Splitsen lost grootte-limieten op, niet snelheid. Voor snelheid: laad data voordat je indexen aanmaakt en verpak batches in transacties.
Werkt dit alleen met MySQL-dumps?
Nee. Splitsen gebeurt generiek bij puntkomma's die statements afsluiten, dus een PostgreSQL- of andere SQL-dump wordt ook veilig gesplitst. De MySQL-specifieke DELIMITER-afhandeling wordt alleen geactiveerd wanneer een dump die syntax daadwerkelijk gebruikt voor stored procedures of triggers - anders heeft het geen effect.
Hoe kies ik een chunkgrootte?
Stem het af op wat het hele bestand afwijst - phpMyAdmin en veel hostingproviders beperken uploads tot ergens tussen een paar MB en een paar honderd MB, dus controleer die limiet en kies een chunkgrootte die daar ruim onder blijft. Kleinere chunks betekenen alleen meer bestanden om in volgorde te importeren, verder geen nadeel.
Hoe we ons verhouden
| Functie | Online Tool Store | Een CLI-script | Een IDE-plugin |
|---|---|---|---|
| Statement-veilige grenzen | ✓ | ✗ | ✓ |
| Behoudt de oorspronkelijke volgorde van statements | ✓ | ✗ | Soms |
| Geen upload van de dump | ✓ | ✓ | ✗ |
| Werkt ook boven hostinglimieten voor uploads | ✓ | Hangt ervan af | ✗ |
| Houdt stored procedures/triggers intact bij een DELIMITER-wijziging | ✓ | Alleen als het script DELIMITER herkent | ✓ |
| Accepteert een gecomprimeerde .sql.gz-dump direct | ✓ | Bevestigd op sqlsplit.com; een simpel script moet meestal eerst gedecomprimeerd worden | ✓ |
SQL Dump Splitter helpt wanneer een import mislukt door bestandsgrootte - het splitst waar SQL het toelaat, decomprimeert een gzipped dump voor je en houdt elke chunk statement-veilig, inclusief stored procedures.