How to Import a SQL Dump That's Too Big

The dump is 2.1 GB. The hosting control panel accepts 50 MB. Your first instinct is to split the file with split -l, which produces forty-three files, none of which is valid SQL, because the split landed in the middle of an INSERT statement.

Large dumps are a routine part of moving a database between environments, and the tooling for importing them is often the most restrictive part of the whole stack.

What’s actually inside a dump

A dump file is a script, not a data format. It contains statements in a specific order: schema definitions first, then the data, then indexes and constraints. Some dumps interleave these; some wrap everything in one transaction.

The order matters because the statements depend on each other. You can’t insert a row into a table that doesn’t exist, and you can’t add a foreign key constraint before the rows it references are present. That’s why the safe restore order is schema, then data, then constraints and indexes — and why splitting a dump naively so often produces a file that fails halfway.

Splitting has to respect statement boundaries. A single INSERT in a mysqldump file can be megabytes long, containing thousands of rows in one statement. Cut it anywhere but at the semicolon and both halves are invalid.

Why people get stuck here

• Upload limits. Shared hosting, phpMyAdmin, and managed database consoles all cap file size, often well below what a real database produces.
• Naive line splitting. split doesn’t know what SQL is, and extended INSERT syntax means line boundaries and statement boundaries rarely coincide.
• Timeouts. A web-based import that takes longer than the request timeout dies partway, leaving a half-loaded database.
• Constraint failures. Loading data before the tables that data references exist.

What good splitting looks like

Chunks that end at semicolons

Every output file must be independently valid SQL. That means splitting only at statement boundaries, even when it makes chunk sizes uneven.

Schema, data, constraints — in that order

Separate the structure from the content. Load the schema, then each data chunk, then the indexes and foreign keys last. Adding indexes after the data is also dramatically faster than maintaining them during the load.

Predictable, sortable filenames

01-schema.sql, 02-data-users.sql, 99-constraints.sql. When you’re loading forty files by hand at midnight, numeric ordering is worth more than descriptive names.

Common mistakes to avoid

• Splitting by line count and assuming the result is valid SQL.
• Loading chunks out of order because the file manager sorted them alphabetically — 10 before 2.
• Importing through a web interface with a short timeout when a command-line client is available.
• Leaving indexes in place during a bulk load, which slows the import substantially.
• Not disabling foreign key checks during a data load that the dump expects to be wrapped in them.

How to do it with SQL Dump Splitter

The SQL Dump Splitter reads the dump in your browser — nothing is uploaded, which matters when the dump contains production data.

1. Add the dump file and set a chunk size your import tool or host will accept.
2. Choose how to split: at statement boundaries, per table, or per INSERT batch.
3. Keep schema and constraints as separate files rather than mixed into the data.
4. Load the results in numeric order — schema first, constraints last.
5. Verify row counts against the source before pointing anything at the new database.

For the fastest path when you have shell access, MySQL’s own reload documentation covers the command-line approach. Other database utilities are in the tools directory.

Frequently asked questions

Why can’t I just split the file anywhere?

Because a split inside a statement produces two invalid files. Extended INSERT statements routinely span thousands of lines, so line-based splitting almost guarantees a broken chunk.

Why must constraints load last?

Foreign keys reference rows in other tables. Add the constraint before those rows exist and it fails validation. Loading constraints after all the data means they validate once, against a complete database.

My import is still slow after splitting. Why?

Splitting solves file size, not speed. For speed: load data before creating indexes, wrap batches in transactions, and use a command-line client rather than a web interface.

Final thought

Split at semicolons, load in numbered order, add indexes last. Those three rules turn a failing 2 GB import into a boring one, which is exactly what a database restore should be.

Try the free SQL Dump Splitter