JA
/
EN

How to Export a Database in phpMyAdmin [2026 Edition]: Settings That Prevent Import Failures

  • WordPress

When exporting a database in phpMyAdmin for a server migration or backup, sticking with the default “Quick” export settings can cause errors on import, or tables that don’t restore correctly. This guide walks through the settings worth checking before you export, with real screenshots.

About this article: This is not official phpMyAdmin documentation — it’s a walkthrough based on real screenshots from the author’s own environment. The default values and behavior of these options can vary depending on your phpMyAdmin / MySQL or MariaDB version. Please also check the official phpMyAdmin documentation for the exact specifications.

 

STEP 1: Select the database to export and open the “Export” tab

Log in to phpMyAdmin and select the database you want to export from the menu on the left. Click the “Export” tab at the top, and choose “Custom – display all possible options” (「詳細 – 可能なオプションをすべて表示」) instead of the default “Quick” (「簡易」) method.

Selecting a database and choosing Custom export in phpMyAdmin (Japanese UI)

 

STEP 2: Check the format and table selection

On the screen that appears after choosing “Custom,” check the following two things:

  • Format: make sure it’s set to “SQL”
  • Tables: make sure every table in the list is checked (you can check them all at once with “Select all”)
Confirming the format is SQL and all tables are selected (Japanese UI)

 

STEP 3: Add the DROP TABLE-related statements under Object creation options

Scroll down to “Object creation options” (「生成オプション」). Here, enable the option to add “DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER” statements (it’s off by default).

Turning this on means that even if a table with the same name already exists at your import destination, running the exported SQL will drop and recreate it — which makes overwriting easier when you import.

Also, “AUTO_INCREMENT value,” “Add CREATE VIEW statement,” “Add CREATE PROCEDURE / FUNCTION / EVENT statement,” “Add CREATE TRIGGER statement,” and “Enclose table and column names with backquotes” should already be enabled by default — just make sure you haven’t accidentally turned any of them off.

Enabling the option to add DROP TABLE and related statements in Object creation options (Japanese UI)

 

STEP 4: Check the encoding conversion setting

Leave “Encoding conversion” (「エンコーディングへの変換」) set to its default of “None” (「なし」). Converting it to EUC or Shift-JIS here can cause garbled characters (mojibake) if your site is originally running on UTF-8.

Leaving Encoding conversion set to None (Japanese UI)

 

STEP 5: Consider compression or splitting for large files

Under “Output” (「出力」), the “Compression” (「圧縮」) option lets you export the SQL file in a compressed format — useful when your data is large.

Choosing zip format under the Compression option in Output (Japanese UI)

Depending on where you’re importing to, there may be a limit on the file size you can upload. In the author’s own environment, files over 32MB uncompressed were compressed to zip, and if the unzipped size came out over 105MB, the tables being exported were split across multiple exports instead. The exact limits depend on your server and phpMyAdmin configuration, so be sure to check the limits on the environment you’re importing into as well.

 

Handling the exported file

The exported SQL file contains the raw contents of your database — including member information and password hashes. Keep the following in mind:

  • Don’t store it in a publicly accessible directory on your server
  • Delete the export file once you’re done with it
  • If sharing it with a third party, avoid plain-text channels like chat or email — use a secure method instead

 

Common issues and how to fix them

SymptomLikely causeFix
Import fails with an error like “table already exists”The DROP TABLE-related statements weren’t added during exportRe-export with the STEP 3 setting enabled
Characters are garbled (mojibake) after importThe encoding conversion at export time, or the character-set settings at the import destination, are affecting thingsChoose “None” for encoding at export time, and also check the character-set settings on the destination database/tables
The file is too large to importIt wasn’t compressed, or the tables weren’t splitCompress it (e.g. zip), or export the tables in separate batches

 

Summary

You can still export from phpMyAdmin with the default “Quick” settings, but import trouble usually comes down to two things people miss: adding the DROP TABLE-related statements, and the encoding setting. We’d recommend switching to “Custom” and checking the items in STEP 1 through STEP 5 before you export.

Share this article

Next Article

Previous Article