phpMyAdmin Import Stuck or Failing on Large SQL Files? Fix It

You picked a .sql file in phpMyAdmin, hit Go, and the tab just sat there — then either timed out, threw a size error, or silently dropped you back at a blank import screen with no obvious reason why. Big database dumps break phpMyAdmin in a handful of very specific, very fixable ways. Here's what's actually going on and how to get the import done.

Symptom: What a Failed Large Import Looks Like

It rarely fails the same way twice. On a large .sql file (usually anything past 30-50 MB) you'll see one of these:

• "You probably tried to upload a file that is too large" — phpMyAdmin rejects the file before it even starts.
• The browser tab spins for a minute or two, then comes back to a plain white or blank import page with no error message.
• "Error: 413 Request Entity Too Large" or a Cloudflare/nginx error page instead of phpMyAdmin's own UI.
• The import runs partway — you see a chunk of tables appear — then stops, and the error log shows MySQL server has gone away.
• "#2006 - MySQL server has gone away" or "Got a packet bigger than 'max_allowed_packet' bytes" mid-import.

All of these trace back to one of four limits, and phpMyAdmin hits every one of them before a straight mysql import from the command line ever would.

Cause 1: PHP's Upload Limits Are Too Low

phpMyAdmin runs as a PHP application, so your .sql file has to pass through PHP's own upload ceiling before it even reaches the import engine. Two settings matter:

• upload_max_filesize — the hard cap on any single uploaded file.
• post_max_size — the cap on the whole POST request, which must be equal to or larger than upload_max_filesize, or the upload silently fails.

On shared cPanel hosting, both usually default to something like 64M or 128M — fine for a small site, useless for a 400 MB WooCommerce order-history dump.

Fix It

In cPanel, go to Software > MultiPHP INI Editor, pick your domain, and raise both values (keep post_max_size at least equal to upload_max_filesize):

upload_max_filesize = 1024M
post_max_size = 1024M

Save, then reload phpMyAdmin — no server restart needed on cPanel. If you don't see these fields, your account may be on a shared PHP handler that caps them lower than account level; ask your host to raise the account limit instead.

Cause 2: The Import Times Out Before It Finishes

Even with the file uploaded, phpMyAdmin itself enforces an execution time limit separate from PHP's max_execution_time — by default it caps a single import at 300 seconds (5 minutes) regardless of what your PHP config allows. A large dump with big INSERT statements or a lot of indexes to rebuild can easily blow past that.

Fix It

Two settings need to move together:

On most shared cPanel accounts you can't touch phpMyAdmin's own config.inc.php, so raising PHP's max_execution_time only gets you partway. If the import still stalls in the same spot every time, stop trying to force it through the browser — split the file or use SSH instead (below). Fighting a 300-second GUI limit with a 40-minute import is a losing battle.

Cause 3: max_allowed_packet Rejects a Big Row

If the import gets partway through and then dies with MySQL server has gone away or Got a packet bigger than 'max_allowed_packet' bytes, the problem isn't the whole file — it's one single row that's too big for MySQL to accept in one piece. This is common with WordPress dumps that have large serialized wp_options rows, base64-encoded images pasted into post content, or WooCommerce order meta.

Fix It

Check the current value:

mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';"

On shared cPanel hosting, raise it via WHM > MySQL/MariaDB Configuration > Config Editor (ask support if you're not on WHM). On a VPS you own, edit /etc/my.cnf or /etc/mysql/mariadb.conf.d/50-server.cnf:

[mysqld]
max_allowed_packet = 256M

Then restart: systemctl restart mysql (or mariadb). 256M is generous for almost any WordPress or WooCommerce dump; go higher only if you know you have unusually large blob rows.

The Fix That Sidesteps All Three: Import via SSH

If your account has SSH access, this is faster and far more reliable than fighting phpMyAdmin's upload and timeout ceilings — there's no browser session to time out and no PHP upload cap involved at all.

1. Upload the .sql file via SFTP or File Manager (gzip it first if it's large — gzip database.sql shrinks a typical WordPress dump by 80-90%).
2. SSH in and import directly:

# plain .sql file
mysql -u username_dbuser -p username_dbname < database.sql

# gzipped file, no need to unzip first
gunzip < database.sql.gz | mysql -u username_dbuser -p username_dbname

If you don't have shell access but do have WP-CLI enabled through cPanel Terminal, WordPress dumps import cleanly with:

wp db import database.sql

No SSH at all? Split the export into smaller chunks. In phpMyAdmin, use Export > Custom and tick "Maximal size of created file" to auto-split by table, or run each large table's export separately and import them one file at a time — tedious, but it keeps every single upload under the failing threshold.

Prevention: Stop This Before the Next Migration

• Always export as gzip (Export > Custom > Compression: gzip) — smaller upload, and it often finishes before the timeout even becomes relevant.
• For anything over ~200 MB, plan on SSH or WP-CLI from the start rather than discovering phpMyAdmin's limits mid-migration.
• Set upload_max_filesize and post_max_size generously on any account you know will handle large media-heavy WooCommerce or multisite databases.
• Before a migration, run SHOW VARIABLES LIKE 'max_allowed_packet'; on both the source and destination server — mismatches here cause the exact same error on the way out as on the way in.

Quick Reference