What's the Best Chunk Size to Split a SQL File?
By size or by lines? 10MB or 50MB? The right answer depends on how you're importing. A practical cheat sheet.
There's no single magic number — the ideal chunk size is whatever reliably imports without hitting your environment's limit, with a comfortable margin. Here's how to pick it for your situation.
The cheat sheet
By size or by line count?
Split by file size when the limit you're fighting is an upload cap (phpMyAdmin's 'max file size'). Split by line count when you care about how long each import runs or when statements are roughly uniform. For most people fighting upload limits, split by size.
If the cap is 10MB, target 8MB chunks — not 9.9MB. The header repeated in each chunk and slight overhead can push a 'just under' file over the line.
The real rule: smaller is safer
More chunks means more imports, but each one is far more likely to succeed. A failed 200MB import wastes everything; a failed 10MB chunk costs you one quick retry. When in doubt, go smaller.
What never changes
- Split at statement boundaries, never mid-INSERT
- Keep the SET/charset header in every chunk
- Import the chunks in order
- Verify row counts after the last chunk
Frequently Asked Questions
What's the best chunk size for splitting a SQL file?
For phpMyAdmin on shared hosting, 8–10MB chunks are safest. With raised limits, 20–30MB works. On the CLI you can go to 50MB or skip splitting entirely on a dedicated server. Always leave headroom under the actual limit.
Should I split a SQL file by size or by line count?
Split by file size when fighting an upload cap like phpMyAdmin's max file size. Split by line count when you care about how long each import runs. For most upload-limit cases, splitting by size is the right choice.
Is it better to use more, smaller chunks or fewer, larger ones?
Smaller chunks are safer. A failed large import wastes the whole transfer, while a failed small chunk is a quick retry. Use the smallest size that's still convenient to import in sequence.