2026年7月6日

MySQLのデータベース移行・エクスポート方法 mysqldumpとWP-CLIで安全に移す手順

データベースサーバー

MySQL のデータベースを別のサーバーへ移すときの基本は、mysqldump で SQL ファイルに書き出し、移行先で mysql コマンドで読み込む流れです。WordPress の場合は WP-CLI の wp db export / wp db import でも同じことができます。この記事では、書き出しのオプションの意味、大きなデータベースの扱い、移行先で出やすいエラー（Collation・DEFINER・権限）、WordPress の URL 置換、移行後の確認までを、データベース単体の作業に絞って説明します。ファイルやドメインを含むサイト全体の引っ越しは、この手順の一部としてデータベースを移すことになります。

移行の前に確認すること

移行元と移行先の製品とバージョン。SELECT VERSION(); で確かめます。MySQL 8.0 から MariaDB へ、のように製品をまたぐ場合や、新しい版から古い版へ移す場合は、後で説明する互換性のエラーが出やすくなります
文字コードと Collation。移行元のテーブルが何を使っているかを確認しておくと、移行先での文字化けやエラーの原因を切り分けやすくなります
容量。information_schema.TABLES の DATA_LENGTH と INDEX_LENGTH の合計で、おおよその大きさが分かります。書き出したファイルを置くディスクの空きも確認します
書き込みを止められるか。移行中に移行元でコメントや注文が入ると、その分は移行先に入りません。WordPress ならメンテナンスモードにするか、作業時間を決めておきます

mysqldumpで書き出す

InnoDB のテーブルが中心の WordPress では、次の形が基本になります。

mysqldump -u dbuser -p \
  --single-transaction \
  --default-character-set=utf8mb4 \
  --routines --triggers --events \
  --no-tablespaces \
  wordpress > wordpress.sql

各オプションの意味は次のとおりです。

--single-transaction：1つのトランザクションの中で読み出し、テーブルをロックせずに一貫した状態を書き出します。InnoDB のテーブルでのみ有効で、MyISAM が混ざっている場合は一貫性が保証されません
--default-character-set=utf8mb4：書き出し時の接続の文字コードを明示し、絵文字などが化けるのを防ぎます
--routines --triggers --events：ストアドプロシージャ、トリガー、イベントも含めます。トリガーは既定で含まれますが、明示しておくと意図が分かりやすくなります
--no-tablespaces：MySQL 8.0 の新しい版では、テーブルスペース情報の書き出しに PROCESS 権限が必要になり、権限の少ないユーザーで実行すると Access denied; you need (at least one of) the PROCESS privilege(s) で止まります。WordPress の移行ではテーブルスペース情報は通常不要なので、このオプションで省きます

パスワードは -p の後に続けて書かず、対話で入力します。自動化する場合は権限を絞った ~/.my.cnf に書きます。GTID を有効にした MySQL（マネージド DB に多い）から書き出す場合、ダンプに GTID の設定文が入り、移行先でエラーになることがあります。そのときは --set-gtid-purged=OFF を付けます。MariaDB では同じ役割のコマンドが mariadb-dump という名前になっています（mysqldump も互換名として使える場合が多いです）。

WP-CLIで書き出す

WordPress のディレクトリで実行すると、wp-config.php の接続情報が使われるため、ユーザー名やパスワードを入力せずに済みます。

wp db export wordpress.sql
# 一部のテーブルを除く場合
wp db export wordpress.sql --exclude_tables=wp_actionscheduler_logs

wp db export は内部で mysqldump を呼び出し、追加のオプションも渡せます。ログ系の大きなテーブルを除くとファイルが小さくなりますが、除いたテーブルは移行先には作られません。プラグインが動作に必要とするテーブルかどうかを確かめてから除きます。

大きなデータベースを扱う

数GB を超えるデータベースでは、圧縮して書き出すとディスクと転送時間を節約できます。

mysqldump -u dbuser -p --single-transaction --no-tablespaces wordpress \
  | gzip > wordpress.sql.gz

phpMyAdmin のインポートは、PHP の upload_max_filesize や post_max_size、実行時間の制限に引っかかりやすく、大きなファイルでは途中で止まります。SSH が使える環境ではコマンドでの読み込みのほうが安定します。SSH が使えないレンタルサーバーでは、サーバー会社が用意しているデータベースのインポート機能や、移行用プラグインを検討してください。

移行先で読み込む

移行先に空のデータベースとユーザーを作ってから読み込みます。

CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;

mysql -u dbuser -p --default-character-set=utf8mb4 wordpress < wordpress.sql
# 圧縮ファイルの場合
gunzip < wordpress.sql.gz | mysql -u dbuser -p --default-character-set=utf8mb4 wordpress
# WP-CLI の場合
wp db import wordpress.sql

既存のデータベースに読み込むと、同じ名前のテーブルは上書きされます。移行先に残したいデータがある場合は、読み込む前にそちらもバックアップしてください。

移行先で出やすいエラー

Unknown collation: 'utf8mb4_0900_ai_ci'

MySQL 8.0 以降で書き出したダンプを、MariaDB や MySQL 5.7 に読み込むと出ます。移行先にその Collation が無いためです。移行先を新しい MySQL にそろえるのが根本的な対処ですが、難しい場合はダンプ内の指定を置き換えます。

sed -e 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_520_ci/g' wordpress.sql > wordpress-fixed.sql

置き換えると文字列の比較規則が変わるため、UNIQUE 制約のある列で重複エラーが出ることがあります。置き換えたファイルはステージング環境で読み込んで確かめます。

The user specified as a definer does not exist

ビューやトリガー、ストアドプロシージャには作成者（DEFINER）が記録されています。移行先にそのユーザーがいないと、実行時にこのエラーが出ます。移行先に同じユーザーを作るか、ダンプ内の DEFINER= の部分を移行先のユーザーに書き換えます。WordPress のコアはビューやトリガーを使わないため、出た場合はプラグインや独自に追加したものを確認します。

Access denied や容量のエラー

レンタルサーバーやマネージド DB では、SUPER 権限が必要な文（GTID の設定やバイナリログ関連の設定）がダンプに含まれていると、読み込みが拒否されます。エラーになった行を確認し、書き出し時のオプションで除けるかを調べます。

WordPressのURLを置き換える

ドメインや URL が変わる場合、データベース内の URL を置き換える必要があります。テキストエディタや SQL の REPLACE で一括置換すると、シリアライズされた値（s:20:"..." のように文字数を持つ形式）の文字数が合わなくなり、ウィジェットやテーマの設定が消えることがあります。WP-CLI の search-replace はシリアライズを考慮して置き換えます。

# まずは変更件数だけを確認
wp search-replace 'https://old.example.com' 'https://new.example.com' --dry-run --skip-columns=guid
# 問題なければ実行
wp search-replace 'https://old.example.com' 'https://new.example.com' --skip-columns=guid

投稿の guid 列はフィードの識別子として使われるため、既存の値は変えないのが一般的です。置き換え後はキャッシュ系プラグインやオブジェクトキャッシュを削除してから表示を確かめます。

移行後に確認すること

テーブル数と主要テーブルの行数。移行元と移行先で SELECT COUNT(*) FROM wp_posts; などを比べます
日本語と絵文字が正しく表示されるか。投稿の本文やコメントを数件開いて確かめます
wp-config.php の DB_NAME / DB_USER / DB_PASSWORD / DB_HOST が移行先のものになっているか
管理画面へのログイン、投稿の保存、画像のアップロードといった書き込み操作ができるか
移行元のデータベースはすぐに削除せず、移行先が安定するまで保管しておきます

製品やバージョンの組み合わせによって細かな挙動は変わります（2026年10月現在）。本番で実行する前に、同じ手順をステージング環境で一度通しておくと、エラーの多くを事前に見つけられます。

まとめ

基本は mysqldump で書き出し、mysql で読み込む流れです。WordPress なら wp db export / wp db import も使えます
InnoDB では --single-transaction でロックせずに書き出し、文字コードは utf8mb4 を明示します。権限エラーには --no-tablespaces や --set-gtid-purged=OFF が効く場合があります
新しい MySQL から古い版や MariaDB へ移すときは、Collation と DEFINER のエラーに備えます
URL の置き換えはシリアライズを考慮する wp search-replace で、まず --dry-run から行います
移行後は行数・文字化け・書き込み操作を確認し、移行元のデータはしばらく残しておきます