さくら→Xserver の移行で発生「Unknown collation: ‘utf8mb4_0900_ai_ci’」の直し方

さくらのレンタルサーバで動いていた WordPress を、Xserver など別のサーバーに引っ越す。旧サーバーの phpMyAdmin でデータベースをエクスポートして、新サーバーの phpMyAdmin でインポート — そこで、こんなエラーが出て止まってしまうことがあります。

ERROR 1273 (HY000) at line 25: Unknown collation: 'utf8mb4_0900_ai_ci'

phpMyAdmin のインポートが ERROR 1273 (Unknown collation: utf8mb4_0900_ai_ci) で停止した画面

見慣れないエラーで不安になりますが、先に安心できることを書いておきます。データベースは壊れていません。エクスポートしたファイルも正常です。原因は新旧サーバーのデータベースの「世代の違い」で、エクスポートしたファイルをテキストエディタで 1 回置換するだけで直ります。

この記事は机上の解説ではありません。実際にさくらのレンタルサーバで動いている WordPress のデータベースを Xserver に取り込み、このエラーを実サーバー間で再現したうえで、直るところまで検証しています（上のエラーメッセージはその実際の出力です）。先に結論だけ書いておきます。

エクスポートした .sql ファイル内の utf8mb4_0900_ai_ci を utf8mb4_uca1400_nopad_ai_ci に全置換して、インポートし直す。これで直ります（手順は後述）
ネット上でよく見る「utf8mb4_unicode_ci に置換する」という方法は使わないでください。別のエラーが出るか、気づかない形でデータの扱いが変わります（実測結果を後半で見せます）
VPS やクラウドなどデータベースのバージョンを自分で選べる環境なら、MariaDB 11.4 以降を選べば置換自体が不要です

どんな引っ越しで出るエラーか

このエラーは「MySQL 8 のサーバーから、MariaDB のサーバーへ」データベースを移すときに出ます。国内の大手レンタルサーバーで実際に確認した組み合わせがこちらです。

サーバー	データベース（実測）
さくらのレンタルサーバ	MySQL 8.0 系
Xserver	MariaDB 10.11 系

※ 2026 年 7 月時点・当社検証環境での実測値です。サーバーの世代やプランにより異なる場合があります。

つまり「さくら → Xserver」の引っ越しは、このエラーが出る組み合わせの典型例です。逆向き（Xserver → さくら）では出ません。サーバー間の引っ越しに限らず、本番サイトのバックアップをローカルの開発環境（MariaDB 使用）に取り込むときにも同じエラーが出ます。

誤解しないでほしいのは、どちらのサーバーにも問題は無いということです。MySQL と MariaDB はどちらも WordPress が公式対応するデータベースで、それぞれ正常に動いています。ただ、MySQL 8 が使う「文字の並べ替えルール」の名前（utf8mb4_0900_ai_ci）を MariaDB が知らないため、その名前が書かれたファイルを渡すと「知らない名前です」と拒否される — それがこのエラーの正体です。

なぜ「途中まで」は成功するのか

このエラーには特徴があります。インポートが最初から失敗するのではなく、途中までは成功していることです。エラーで止まっているのは、たいてい WordPress 本体のテーブル（wp_posts や wp_options）ではなく、プラグインが作ったテーブルです。

さくらのレンタルサーバ上の実際の WordPress で調べた結果がこちらです。

テーブル	並べ替えルール（照合順序）
wp_posts / wp_options など WordPress 本体の全テーブル	`utf8mb4_unicode_520_ci`（引っ越しても OK）
一部のプラグインが作ったテーブル	`utf8mb4_0900_ai_ci`（ここで止まる）

WordPress 本体は、テーブルを作るときに並べ替えルールを明示指定する作法を守っているため、どのサーバーでも同じ名前になります。一方、この作法に従っていないプラグインが作ったテーブルは、そのサーバーの初期設定を引き継ぎます。MySQL 8 の初期設定が utf8mb4_0900_ai_ci なので、そこで作られたテーブルだけが引っ越しで引っかかるのです。

どのプラグインのテーブルが該当するかは運次第で、サイトオーナー側で防ぐ方法はありません。何も悪いことをしていないのに引っ越しが失敗するのは、これが理由です。

該当箇所を事前に調べたい場合は、エクスポートした .sql ファイルをテキストエディタで開いて 0900 を検索するのが手軽です。旧サーバーの phpMyAdmin（SQL タブ）で次を実行しても一覧できます。

SELECT TABLE_NAME, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_COLLATION LIKE 'utf8mb4_0900%'
  AND TABLE_SCHEMA = 'あなたのデータベース名';

直し方（レンタルサーバーの場合）

Xserver など移行先がレンタルサーバーの場合の手順です。作業はテキストエディタの置換 1 回だけです。

手順 1: 移行先で置換先のルールが使えるか確認する

移行先サーバーの phpMyAdmin を開き、SQL タブで次を実行します。

SHOW COLLATION LIKE 'utf8mb4_uca1400_nopad_ai_ci';

結果が 1 行返ってくれば使えます（Xserver の MariaDB 10.11 で実測済みです）。

phpMyAdmin の SQL タブで SHOW COLLATION LIKE を実行し utf8mb4_uca1400_nopad_ai_ci が 1 行返った画面

何も返ってこない場合は移行先の MariaDB が古い（10.6 以前）ため、この方法は使えません — その場合は移行先のサーバー・プランの変更を検討してください。

なお確認には必ずこの SHOW COLLATION LIKE を使ってください。phpMyAdmin の照合順序一覧（プルダウンなど）には表示されないのに使えることを実測で確認しています。一覧に無いからといって未対応と判断すると、使える解決策を見逃します。

手順 2: エクスポートした .sql をテキストエディタで置換する

エクスポートした .sql ファイルを VS Code などのテキストエディタで開き、全置換します。

置換前: utf8mb4_0900_ai_ci
置換後: utf8mb4_uca1400_nopad_ai_ci

テキストエディタの全置換で utf8mb4_0900_ai_ci を utf8mb4_uca1400_nopad_ai_ci に置き換える画面

この置換先は、MariaDB 自身が MySQL 互換のために用意している「同じ並べ替えルールの MariaDB での名前」です。比較・並べ替えの動作が実質的に同じであることを実測で確認しています（末尾空白の扱い・絵文字や特殊漢字の区別がすべて一致）。

保存したら、移行先の phpMyAdmin でインポートし直してください。私たちの検証では、さくらから取り出した実データがこの置換だけで Xserver に取り込めるようになりました。前回のインポートで途中まで取り込まれている場合は、いったんデータベース内のテーブルをすべて削除（空に）してからインポートし直すのが確実です。

ファイルが大きすぎてエディタで開けない場合や、SSH が使える方は、コマンド 1 行でも置換できます。

sed -i.bak 's/utf8mb4_0900_ai_ci/utf8mb4_uca1400_nopad_ai_ci/g' dump.sql

最後に 1 つ。この置換をしたことを、引っ越しのメモに残しておいてください。置換後の名前は逆に MySQL には存在しないため、将来このデータベースを MySQL のサーバー（さくらなど）に戻すときは、今度は逆向きの同じエラーが出ます。そのときは逆の置換をすれば戻せます。

直し方（VPS・クラウドでデータベースを選べる場合）

移行先のデータベースのバージョンを自分で決められる環境なら、MariaDB 11.4 以降を選ぶのが最小手数です。

MariaDB 11.4 は MySQL 互換のため、utf8mb4_0900_ai_ci を含む 0900 系の名前 44 個をそのまま受け付ける公式な対応表を内蔵しています（実測: 置換なしのファイルがそのままインポートできました）。

やってはいけない: utf8mb4_unicode_ci への置換

このエラーを検索するとよく出てくる「utf8mb4_unicode_ci に置換すればよい」という方法を、なぜ勧めないのか。実測結果を見てください。同じサーバー上で、並べ替えルールだけを変えて同じ比較をした結果です。

比較	`utf8mb4_unicode_ci`	`utf8mb4_uca1400_nopad_ai_ci`（推奨）
`'abc'` と `'abc '`（末尾に空白）	同じ扱い	別の値
`'🍎'` と `'🍏'`（別の絵文字）	同じ扱い	別の値
`'𠮷'` と `'𩸽'`（特殊な漢字）	同じ扱い	別の値

utf8mb4_unicode_ci は 20 年以上前の古い比較ルールに基づいていて、絵文字や「𠮷」のような特殊漢字を全部「同じ文字」として扱います。元の utf8mb4_0900_ai_ci はきちんと区別するので、置換すると「元のデータベースでは別物だった値」が「同じ値」扱いに変わってしまいます。

これが実害になる瞬間も実測できます。重複禁止（UNIQUE）の設定が付いたデータに、別々の絵文字を 2 件入れてみると:

INSERT INTO uq VALUES ('🍎');  -- 成功
INSERT INTO uq VALUES ('🍏');  -- ERROR 1062: Duplicate entry '?' for key 'v'

別の絵文字なのに「重複エラー」でインポートが失敗します。「Unknown collation を直したら今度は Duplicate entry が出た」という二段目の沼は、これが正体です。運よくインポートが通った場合はもっと厄介で、エラーは出ないまま検索や並べ替えの挙動が引っ越し前と静かに変わります。コメント欄や注文メモなど、絵文字が混ざり得るデータを持つサイトでは、いつか気づかない形で踏みます。

置換先は必ず、動作が同じであることを確認済みの utf8mb4_uca1400_nopad_ai_ci を使ってください。

「ja」など言語名入りの名前が出てきたら

.sql ファイルの検索結果に utf8mb4_ja_0900_as_cs（日本語）のような言語名入りの 0900 系が出てきた場合だけは、置換で解決しようとしないでください。

これらは特定言語専用の並べ替えルールで、MariaDB 側に同じ動作のものが存在しません（MySQL 8 の 89 個の関連ルールを全数突き合わせて、対応先の無い 19 個を実測で特定しています）。たとえば日本語用の utf8mb4_ja_0900_as_cs は「か」と「カ」を同じ文字として扱いますが、名前が似ている MariaDB 側のルールは区別します。「近そうな名前」に置換すると、ひらがな / カタカナの重複判定が引っ越し前と変わってしまいます。

このケースに該当したら、移行先も MySQL 8 系のサーバー（さくらなど）にするのが安全です。ただし言語名入りのルールは、データベースの設定を意図的に変更したサイトでしか通常使われないため、該当するケースはまれです。

まとめ

「Unknown collation: ‘utf8mb4_0900_ai_ci’」は、さくら（MySQL 8）→ Xserver（MariaDB）のような向きの引っ越しで出る。データベースは壊れていない
直し方は .sql 内の utf8mb4_0900_ai_ci を utf8mb4_uca1400_nopad_ai_ci に全置換してインポートし直すだけ（移行先で使えるかは SHOW COLLATION LIKE で先に確認）
utf8mb4_unicode_ci への置換はしない。別のエラー（Duplicate entry）か、静かな挙動変化のどちらかを引き込む
置換したことは引っ越しメモに残す（MySQL のサーバーに戻すときに逆の置換が必要）

この記事の検証環境

さくらのレンタルサーバ（MySQL 8.0 系）の実際の WordPress データベースを Xserver（MariaDB 10.11 系）へ取り込み、エラーの再現から解決までを実サーバー間で検証
MySQL 8.0.46 / MariaDB 10.6.27・10.11.18・11.4.12（docker 公式イメージ）での比較検証
WordPress 6.8.1（テーブルの照合順序の実測に使用）
検証日: 2026-07-31