How to Import and Export a Database with phpMyAdmin

This guide shows you how to copy a MySQL database out to a file and how to load one back in again, using phpMyAdmin, the browser-based database tool that Noiz provides with every hosting account. Copying a database out is called an export (you will also hear it called a "dump" or a "backup"); loading one in is called an import (sometimes a "restore"). You will do this when you back up a site before making changes, when you move a site to or from Noiz, or when a developer hands you a .sql file to load. phpMyAdmin works the same way whether your account is on Plesk, cPanel, DirectAdmin or ISPConfig, so this article is panel-agnostic: the screens described below look identical no matter which control panel got you there. The one part that differs between accounts is the size limit on imported files, and that has a section of its own with the ways around it.

Last reviewed: 27 July 2026, against phpMyAdmin 5.2 (latest stable series). This guide is written for Noiz hosting and is kept current against phpMyAdmin. It complements, and does not replace, the official phpMyAdmin and MySQL documentation linked below. Different control panels bundle slightly different phpMyAdmin builds, so a checkbox may sit in a marginally different place than described, but the terms and the workflow are stable across the 5.x line.

Official Documentation Reference

• Import and export (phpMyAdmin Documentation): the reference for the Export and Import tabs, the Quick and Custom export methods, and the supported file and compression formats.
• Configuration (phpMyAdmin Documentation): covers the UploadDir setting and the options that govern the maximum size of an uploaded import.
• MySQL server has gone away (MySQL Reference Manual): the authoritative explanation of the "gone away" error and its link to max_allowed_packet, which large imports commonly trip over.
• mysqldump (MySQL Reference Manual): the command-line tool to use instead of phpMyAdmin when a database is too large to move through a browser.

Prerequisites

• You can open phpMyAdmin for your account. On ISPConfig you reach it from the Databases list after you log in to the ISPConfig control panel; on Plesk it is under Databases, and on DirectAdmin under MySQL Management. Whichever panel you use, the phpMyAdmin screens from that point on are the same.
• You know a database username and password that can access the database in question. This is the database login, not your control panel login; the two are separate.
• For an import, the destination database must already exist. If you are setting up a new site, create the empty database first by following How to Create a Database and Database User in ISPConfig, then import into it. phpMyAdmin will not create the database for you unless the file you are loading contains its own CREATE DATABASE statement, which most exports do not.

Exporting a Database

An export reads your live database and writes every table structure and every row into a single text file of SQL statements. That file is a complete, portable snapshot: kept somewhere safe it is a backup, and handed to another server it becomes the source for a migration.

1. In the left-hand navigation panel of phpMyAdmin, click the name of the database you want to export. Do not skip this: the tabs at the top behave differently depending on whether a database is selected. With a database selected, the tabs act on that database; with nothing selected, they act on the whole server.
2. Click the Export tab at the top.

Quick export for a straightforward backup

Leave Export method on Quick - display only the minimal options, and leave Format on SQL. SQL is the format to use for anything you intend to load back into MySQL later; the other formats such as CSV and JSON are for handing data to spreadsheets or other programs, not for restoring a database. Click Export (labelled Go in some builds) and your browser downloads a .sql file named after the database. For a small or medium site this is all you need.

Custom export for tables, compression and options

Choose Custom - display all possible options when you need more control. The extra options that matter most are:

• Selecting tables. The Tables box lists every table with all of them selected by default. Use Unselect all and then tick only the tables you want to export a part of the database, which is handy for copying a single large table or for leaving out bulky cache and log tables you do not need to keep.
• Compression. Under the output options, set Compression to gzipped. This produces a .sql.gz file that is typically five to ten times smaller than the plain .sql, because SQL text compresses very well. A gzipped export downloads faster, stores smaller, and, importantly, imports straight back into phpMyAdmin without you having to unzip it first. This is the single most useful habit to adopt, because it is also what lets a larger database slip under the import size limit described later.
• Structure and data. Leave the object creation options at their defaults. A standard SQL dump includes an Add DROP TABLE option; when enabled, the file drops each existing table before recreating it, so re-importing over an existing database replaces it cleanly rather than colliding with tables that are already there. That is usually what you want for a restore, but be aware it will discard the current contents of any table it recreates.

Click Export to download the file. Keep the downloaded file somewhere reliable and note which database and which date it came from; a backup you cannot identify later is little better than no backup at all.

Importing a Database

An import runs the statements in a .sql file against a database, recreating its tables and rows. phpMyAdmin reads plain .sql files and compressed .sql.gz, .sql.zip and .sql.bz2 files directly, detecting the compression from the file extension, so a gzipped export can go straight back in with no unzipping.

Select the destination database first

This is the step people most often get wrong, and it is worth slowing down for. In the left-hand panel, click the name of the database you want to import into before you touch the Import tab. If you open Import while sitting at the server level with no database chosen, and the file does not name a database of its own, phpMyAdmin has nowhere to put the tables and you get a #1046 No database selected error. Worse, if the file was exported with a hard-coded database name, an import at the wrong level can load the tables into a database you did not intend. Selecting the correct database first removes both problems.

1. With the destination database selected, click the Import tab.
2. Under File to import, click Browse your computer and choose your .sql or .sql.gz file. Note the maximum size shown in brackets next to the button, for example (Max: 50MiB); your file must be smaller than this. The next section deals with what to do when it is not.
3. Check Character set of the file. Leave it on utf-8 for any modern export. Only change it if you know the file was created from an older database in a different character set; getting this wrong is what produces garbled accented characters after an import, covered under Troubleshooting.
4. Leave the Format on SQL.
5. Click Import. On a large file the page may sit for a while as it works; wait for the green success message rather than reloading, which would start the import again.

Two options on the Import page are worth knowing about:

• Enable foreign key checks is ticked by default. If an import fails partway through with a foreign key error, unticking this box tells MySQL not to enforce the relationships between tables while the file loads, which lets tables come in regardless of the order they appear in the file. See the foreign key note under Troubleshooting.
• Partial import includes an option to let phpMyAdmin pause and resume if the import gets close to the server's PHP time limit, and a field to skip a number of queries from the start. The skip field is how you resume a large import that stopped partway, by telling it to continue past the statements that already ran.

The Upload Size Limit and How to Work Around It

Every phpMyAdmin import is capped by a maximum file size, shown on the Import page as (Max: ...). That figure is set by the web server's PHP configuration, not by phpMyAdmin itself, so it varies between Noiz servers and plans. When your file is larger than the limit, the upload is rejected before any data is loaded. You have four practical ways around it, in the order most people should try them:

• Gzip the export. The limit applies to the size of the file you upload, and phpMyAdmin unpacks a compressed file on the server side after it arrives. A .sql.gz is often a fraction of the size of the plain .sql, so re-exporting with Compression: gzipped (or gzipping the file you already have) is frequently enough on its own. Always try this first.
• Split the export into smaller files. Use the Custom export to save a few tables at a time into separate files, each under the limit, then import them one after another. Selecting the destination database first, as above, keeps every piece landing in the right place.
• Use the command line over SSH. For a genuinely large database this is the right tool, and it sidesteps the browser limit entirely. See the next section. SSH is available on VPS, dedicated and shell-user accounts; if your plan does not include shell access, use the last option.
• Ask Noiz to load it server-side. On a managed plan, the Noiz support team can import a large file directly on the server, past the browser limit, if you provide the file and name the destination database. This is the simplest route when the file is very large and you would rather not touch the command line.

When to Use the Command Line Instead

phpMyAdmin is the right tool for small and medium databases, roughly up to a few tens of megabytes. Beyond that, browser and PHP time limits start to bite, a slow upload can be cut off partway, and a single oversized statement in the file can trigger the "gone away" error described below. For large databases the command line, over an SSH connection, is faster and far more reliable because it streams the data straight into MySQL with none of the browser in the way. SSH access comes with VPS, dedicated and shell-user accounts.

To export a database to a file, and to a compressed file:

mysqldump -u dbuser -p dbname > backup.sql
mysqldump -u dbuser -p dbname | gzip > backup.sql.gz

To import a file into an existing database, from a plain dump and from a gzipped one:

mysql -u dbuser -p dbname < backup.sql
zcat backup.sql.gz | mysql -u dbuser -p dbname

Replace dbuser and dbname with your own values; the -p flag makes each command prompt for the database password so it never appears in your shell history. On an ISPConfig shared account, remember that both the database name and the user carry your account prefix, so the real values look like c1dbname and c1dbuser. If a command asks for a host, the database runs on the same server as your site, so the host is localhost. As with an import in phpMyAdmin, the destination database must already exist before you load into it.

Getting Character Set and Foreign Keys Right

Two things quietly cause most "the import worked but the data looks wrong" complaints, and both are easy to head off.

Character set. A database stores text in a particular character set, and the export records which one. If you import a file using a different character set from the one it was written in, accented and non-English characters come out mangled, so café becomes café. Modern sites are UTF-8, and leaving Character set of the file on utf-8 is correct almost every time. The exception is an export taken from an older database that used latin1; for those, match the setting to the original. The safe rule is to keep the export and the import on the same character set from end to end.

Foreign keys. Many databases define relationships between tables, where rows in one table point at rows in another. A full export made by phpMyAdmin or mysqldump handles this for you by switching the checks off at the top of the file and back on at the end, so a complete restore loads cleanly. The trouble appears when you import only part of a database, or load tables in the wrong order, and a row points at another row that has not been created yet. That produces a Cannot add or update a child row error. Unticking Enable foreign key checks on the Import page lets the tables load regardless of order, after which the relationships line up once every table is present.

Troubleshooting

• Symptom: the import fails with MySQL server has gone away. A single statement in the file was too large for the server to accept in one piece, most often a row containing a large block of data such as an image stored in the database. The controlling limit is max_allowed_packet. The dependable fix is to import over SSH and raise the limit for that one command, for example mysql --max_allowed_packet=256M -u dbuser -p dbname < backup.sql. On a shared plan where you cannot change server settings, ask the Noiz support team to load the file for you. This error is one of the clearest signs that a database has outgrown browser-based import.
• Symptom: the file is bigger than the (Max: ...) figure and will not upload. Gzip the export so the uploaded file is smaller, split it into several smaller files, import over SSH, or ask Noiz to load it server-side, as set out in the size-limit section above.
• Symptom: #1046 No database selected. You started the import without choosing a database. Click the destination database in the left-hand panel first, then reopen the Import tab and try again.
• Symptom: accented or non-English characters appear garbled after the import, such as é in place of é. The character set chosen for the import did not match the one the file was written in. Re-import the same file with Character set of the file set to match the original database, which for older data is often latin1 rather than utf-8.
• Symptom: Cannot add or update a child row: a foreign key constraint fails. Tables are loading in an order that breaks the links between them, which happens with partial imports. Untick Enable foreign key checks on the Import page and import again.
• Symptom: a large import stops partway with a timeout and only some tables arrive. The server's PHP time limit was reached before the file finished. Import a gzipped copy to move less data over the wire, use the Partial import skip field to resume past the statements that already ran, or switch to the command line, which has no such time limit.
• Symptom: phpMyAdmin rejects the database username and password. Use a database user with access to the database, not your control panel login; the two are different. On ISPConfig the database user includes your account prefix, for example c1dbuser rather than dbuser.

If an export or import will not go through, or a database is simply too large to move comfortably through a browser, open a support ticket with the Noiz support team. Tell them the database name, whether you are exporting or importing, and the exact error message, and attach the file if you have one. On a managed plan the team can run the transfer directly on the server for you. Never include a database password in a ticket.