SQL Dump Splitter: Split Large SQL Files for Import

Anyone who has tried to restore a database through phpMyAdmin knows the wall: your .sql dump is 500 MB, the upload limit is 50 MB, and the import dies halfway with a timeout. A SQL dump splitter breaks that oversized file into smaller chunks that fit within upload and execution limits, so each piece imports cleanly. This guide covers when you actually need to split a dump, the free tools that do it, and the command-line methods that are often faster and more reliable — handy whenever you're migrating a database or restoring a large scraped dataset.

Why large SQL dumps fail to import

A SQL dump is just a text file full of CREATE TABLE and INSERT statements produced by mysqldump or a similar tool. Restoring it means running every statement against the target database. That's simple in principle, but web-based tools like phpMyAdmin and Adminer impose hard limits that big dumps blow past:

• upload_max_filesize and post_max_size — PHP caps how large an uploaded file can be. A dump bigger than this is rejected outright.
• max_execution_time and max_input_time — PHP kills scripts that run too long, so a big import times out mid-restore, leaving the database half-loaded.
• memory_limit — very large statements can exhaust the memory PHP is allowed to use.

Shared hosting is the classic trap: you often can't change these limits, and the web interface is the only access you have. Splitting the dump into pieces that each fit under the limits, then importing them one after another, sidesteps every one of these ceilings.

Option 1: a dedicated SQL dump splitter tool

The simplest fix for non-technical users is a GUI dump splitter. These read a large .sql file and write out a series of smaller .sql files, each below a size you choose, while being careful not to cut a SQL statement in half — a naive split at an arbitrary byte would corrupt the dump.

The best-known free option is SQLDumpSplitter3, a free desktop tool (Windows, macOS, and Linux) that splits a large MySQL dump into smaller files by a target size you set. You point it at the dump, choose a chunk size that's comfortably under your host's upload_max_filesize, and it produces numbered files you import in order through phpMyAdmin. It's the modern successor to the older SQLDumpSplitter2 that circulated years ago.

The workflow is straightforward:

1. Split the dump into chunks (for example, 40 MB each if your upload limit is 50 MB).
2. In phpMyAdmin, import the chunk containing the schema (CREATE TABLE statements) first.
3. Import the remaining data chunks in order.

Option 2: BigDump (staggered import)

If the problem isn't upload size but execution time — the import starts fine but times out — a staggered importer solves it without splitting files by hand. BigDump is a long-standing free PHP script that reads a large dump in small batches, running a limited number of queries per request and then reloading itself to continue, so it never trips the max_execution_time limit. You upload the dump to your server via FTP, drop the BigDump script beside it, and run it from the browser; it grinds through the whole file in safe increments. It's especially useful on shared hosting where you can't raise PHP limits but can upload files by FTP.

Option 3: import from the command line (usually the best)

If you have shell or SSH access, skip the web interface entirely — it's the source of most of these limits. Piping a dump straight into the mysql client has no upload cap and no PHP timeout, and it's dramatically faster than phpMyAdmin for large files:

mysql -u username -p target_database < big_dump.sql

For a compressed dump, stream it through gunzip without ever unpacking the whole thing to disk:

gunzip < big_dump.sql.gz | mysql -u username -p target_database

Or from inside the MySQL shell:

mysql> USE target_database;
mysql> SOURCE /path/to/big_dump.sql;

If a single dump is still unwieldy (say you want to import table by table, or resume after a failure), split it on the command line. To split by size while keeping whole lines intact:

# split into ~40 MB pieces, breaking only at line boundaries
split -C 40m --additional-suffix=.sql big_dump.sql chunk_

Because a mysqldump file has one statement per line by default, splitting at line boundaries keeps statements intact. Import the pieces in order (schema first). For extracting a single table's data from a giant multi-table dump, sed or awk can pull out the section between two CREATE TABLE markers, though a targeted re-dump is usually cleaner.

Option 4: raise the limits (when you control the server)

If the database is on a server you administer, the cleanest fix is often to lift the limits rather than split anything. In php.ini (or your host's PHP settings):

upload_max_filesize = 512M
post_max_size = 512M
max_execution_time = 600
memory_limit = 512M

Restart the web server (and PHP-FPM if you use it) and phpMyAdmin will accept much larger dumps. This is only appropriate on your own server — on shared hosting you typically can't change these, which is exactly why splitters and staggered importers exist.

Avoid the problem at the source

Better still, produce a dump that's easier to load in the first place. A few mysqldump habits make large restores far smoother:

• Compress it. mysqldump ... | gzip > dump.sql.gz shrinks the file for transfer, and you import it straight from the gzip stream (see above).
• Use bulk inserts. The default extended-insert format packs many rows into each INSERT, which imports much faster than one row per statement.
• Dump per table. For selective restores, dump big tables individually so you never have to split later.
• Consider parallel tools. For very large databases, mydumper/myloader dump and load in parallel across multiple threads, vastly outpacing a single-threaded mysqldump restore.

Which method should you use?

The bottom line

A SQL dump splitter is the right rescue when you're stuck behind a web interface's upload and timeout limits — a free tool like SQLDumpSplitter3 or a staggered importer like BigDump will get a large dump imported without touching server settings. But whenever you have command-line access, importing directly with mysql (ideally from a compressed dump) is faster and avoids the whole class of problems.

If those large dumps are exports of scraped data and moving them between servers has become a recurring chore, scraping.pro can deliver structured data straight into your database or as a managed data feed — so the data lands where you need it instead of arriving as an unwieldy file you have to split and babysit.