Importing Large SQL Files with phpMyAdmin: Limits and Timeouts

You select an SQL backup, start the import, and receive a blank page or timeout several minutes later. Retrying immediately is tempting. However, the first attempt may already have created tables and written thousands of records. Running the file again can fail for an entirely different reason.

First identify the failing layer: did the upload reach PHP, did phpMyAdmin run out of time, or did the database reject a statement? These cases need different fixes. Use a separate restore environment rather than repeatedly testing against production data.

Match the error to the relevant limit

• Upload size warning: inspect PHP's upload_max_filesize and post_max_size.
• HTTP 413: a web server or reverse proxy may reject the request before PHP handles it.
• HTTP 504 or a disconnected browser: an upstream timeout does not prove that database activity has stopped.
• Error 1153 or max_allowed_packet: the size of one statement or packet matters, not just the whole file.
• Error 1062 or 1273: investigate duplicate keys or unsupported collations rather than upload settings.

Keep the complete error, time, and any SQL line number. Compare the browser message with PHP and web-server logs. A spinning browser indicator cannot reliably tell you whether the database is still working.

Check the PHP instance that serves phpMyAdmin

The command-line PHP configuration may differ from the PHP-FPM pool serving the website. Check the domain's actual web configuration. Do not leave a public phpinfo page online. For an upload around 150 MB, these are illustrative values, not a universal server recommendation:

upload_max_filesize = 192M
post_max_size = 224M

post_max_size must allow room for the surrounding form data. Verify that the intended PHP service picked up the change. Accepting an upload does not resolve memory or execution limits. Raising memory limits without considering available RAM, or removing all timeouts, can affect other sites. For larger backups, a database client is often easier to supervise.

Inspect where the dump will write

Selecting a test database at connection time is not sufficient protection. A dump may contain USE, CREATE DATABASE, or DROP TABLE statements. Inspect its schema commands, preserve the original, and use an account whose permissions restrict writes to the restore area.

The target should be empty, have sufficient storage, and be disconnected from the live application. Keep backups containing customer data outside the web root. Check that the target supports the storage engines and server-specific features used in the dump.

Import with the mysql client's SOURCE command

Run the following in your operating-system terminal. Create the example restore account and database beforehand. Let the client prompt for the password rather than putting it in the command:

mysql --default-character-set=utf8mb4 -u restore_user -p restore_test

Inside the client, verify the host and selected database before reading the file:

SELECT @@hostname, VERSION(), DATABASE();
SOURCE /secure/backups/site.sql;

The path belongs to the computer running the client, even if the database is remote. On Windows, a path without spaces such as SOURCE C:/Backups/site.sql; avoids shell input-redirection differences. Inspect every error, including earlier errors followed by successful statements. Check your client version's behavior after an error rather than assuming the whole import stopped.

When the upload succeeds but a packet is too large

SHOW VARIABLES LIKE 'max_allowed_packet';

This reports the server value; clients also have packet limits. A large INSERT or BLOB may exceed them. Measure the offending statement before changing server-wide limits. If you can regenerate the dump, smaller INSERT groups may help, but they cannot shrink a single large field. Compressing the file will not solve a statement-size problem.

Do not split SQL at arbitrary text lines: strings and statements can span lines. Wrapping a dump in a transaction also does not remove implicit commits caused by DDL.

Before retrying a partial restore

Inspect the failed test area and prepare a clean one rather than emptying production tables. If keys collide, use the Duplicate Entry 1062 workflow. After import, perform restore verification; file acceptance is not evidence that all expected data returned.

References: phpMyAdmin FAQ, MySQL batch commands, and packet-size errors.