MySQL の文字コードは「どの文字を保存できるか」、Collation（照合順序）は「文字列をどう比較し、どう並べるか」を決める設定です。WordPress で使うなら、文字コードは utf8mb4 を選び、Collation はサーバー・データベース・テーブルでそろえておくのが基本です。この記事では、設定がどの階層で決まるのか、今の値をどう確認するのか、my.cnf と wp-config.php で何を設定するのか、そして日本語で起きやすい比較の落とし穴を順に説明します。
文字コードとCollationは5つの階層で決まる
MySQL の文字コードと Collation は1か所の設定ではなく、次の階層ごとに持っています。上の階層は「下の階層を作るときの既定値」で、すでに作られたものには自動では反映されません。
- サーバー（
character_set_server/collation_server）：新しいデータベースを作るときの既定値 - データベース：新しいテーブルを作るときの既定値
- テーブル：新しい列を追加するときの既定値
- 列：実際にデータが保存される単位。最終的に効くのはここ
- 接続（
character_set_client/character_set_connection/character_set_results）：アプリと MySQL の間でやり取りする文字コード
「サーバーの設定を utf8mb4 に変えたのに、絵文字が保存できない」という相談の多くは、既存のテーブルや列が古い文字コードのまま残っていることが原因です。設定を変えるときは、どの階層を変えたのかを意識してください。
文字コードは utf8mb4 を選ぶ
MySQL の utf8 は歴史的な事情から1文字最大3バイトの utf8mb3 の別名で、4バイトの文字（絵文字や一部の漢字）を保存できません。MySQL 8.0 では utf8mb3 は非推奨になっており、新しく作るものは utf8mb4 を選びます。
既定値は製品とバージョンで異なります（2026年10月現在）。
- MySQL 8.0 以降：既定の文字コードは
utf8mb4、Collation はutf8mb4_0900_ai_ci - MySQL 5.7 以前：既定は
latin1だったため、古い環境から引き継いだデータベースは要注意 - MariaDB：長く
latin1が既定で、新しい系列でutf8mb4に切り替わっています。正確な切り替え版は MariaDB の公式ドキュメントで確認してください
Collationの名前の読み方
Collation の名前は「文字コード_規則_比較の厳しさ」の形になっています。
utf8mb4_0900_ai_ci：Unicode 9.0 ベースの規則（MySQL 8.0 以降）。アクセントを区別せず（ai）、大文字小文字を区別しない（ci）utf8mb4_unicode_520_ci：Unicode 5.2 ベースの規則。MariaDB や MySQL 5.7 でも使えるutf8mb4_unicode_ci：Unicode 4.0 ベースの古い規則utf8mb4_general_ci：簡略化された高速な規則。並び順の正確さは落ちるutf8mb4_bin：バイト値で比較。大文字小文字も濁点もすべて別の文字として扱う
MySQL 8.0 には日本語向けの utf8mb4_ja_0900_as_cs などもあります。どれを選ぶかは「検索や重複チェックで何を同じ文字とみなしたいか」で決まります。
日本語で起きやすい比較の落とし穴
_ai_ci 系の Collation は、アクセントや大文字小文字を無視して比較します。日本語では、この「無視する」範囲に濁点・半濁点やひらがな・カタカナの違いが含まれることがあり、意図しない一致が起きます。言葉で覚えるより、実際の環境で確かめるのが確実です。
SELECT
'ハハ' = 'パパ' COLLATE utf8mb4_0900_ai_ci AS ai_ci,
'ハハ' = 'パパ' COLLATE utf8mb4_ja_0900_as_cs AS ja_as_cs,
'ハハ' = 'パパ' COLLATE utf8mb4_bin AS bin_cmp;結果が 1 なら同じ文字列とみなされています。この違いは、UNIQUE 制約や WHERE の検索結果に直接影響します。たとえば、ユーザー名やタグ名に UNIQUE を付けた列で「別の言葉なのに重複エラーになる」場合は、Collation の比較規則を疑います。
utf8mb4_0900_ai_ci などの 0900 系は、末尾の空白を無視しない（NO PAD）点も古い Collation と異なります。'abc' と 'abc ' の比較結果が変わるため、Collation を変更する前にアプリ側の挙動を確かめてください。
今の設定を確認する
まずはサーバーと接続の値を見ます。
SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';データベース、テーブル、列の単位では information_schema を使います。wordpress の部分は実際のデータベース名に置き換えてください。
-- データベースの既定値
SELECT SCHEMA_NAME, DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME
FROM information_schema.SCHEMATA
WHERE SCHEMA_NAME = 'wordpress';
-- テーブルごとの Collation
SELECT TABLE_NAME, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'wordpress';
-- 文字列の列ごとの文字コードと Collation
SELECT TABLE_NAME, COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'wordpress' AND CHARACTER_SET_NAME IS NOT NULL;テーブルごとの結果に複数の Collation が混ざっていたら、後から入れたプラグインのテーブルや、移行のときに作り直したテーブルが原因であることが多いです。
サーバーの既定値を my.cnf で設定する
新しく作るデータベースの既定値は、MySQL の設定ファイル（/etc/mysql/my.cnf や /etc/my.cnf、ディストリビューションによっては conf.d 配下）で指定します。
[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_0900_ai_ci
[client]
default-character-set = utf8mb4MariaDB や MySQL 5.7 では utf8mb4_0900_ai_ci が存在しないため、utf8mb4_unicode_520_ci などに置き換えます。設定後は MySQL を再起動し、SHOW VARIABLES で反映を確かめます。ここで変わるのは既定値だけで、既存のデータベースやテーブルの設定はそのままです。レンタルサーバーやマネージド DB では設定ファイルを直接触れず、管理画面やパラメーターグループで指定する場合があります。
WordPress側の設定（wp-config.php）
WordPress は接続時に文字コードを指定し、テーブルを作るときにも文字コードと Collation を付けます。その値は wp-config.php の2つの定数で決まります。
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );DB_COLLATE を空にしておくと、WordPress がデータベースの機能に合わせて Collation を選びます。WordPress のバージョンや環境によりますが、多くの場合 utf8mb4_unicode_520_ci などの汎用的な Collation が使われます。特定の Collation に統一したい事情がある場合だけ値を入れます。既存サイトでこの値を変えても、作成済みのテーブルは変わりません。
既存のデータベースとテーブルを変更する
既存のものを変えるには、階層ごとに ALTER 文を実行します。作業前にデータベース全体のバックアップを取り、ステージング環境で先に試してください。
-- データベースの既定値（今後作るテーブルに効く）
ALTER DATABASE wordpress
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;
-- テーブルと、その中の文字列の列をまとめて変換
ALTER TABLE wp_example
CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;CONVERT TO はテーブルを作り直すため、大きなテーブルでは時間がかかり、その間は書き込みが待たされることがあります。また、インデックスの長さ制限（InnoDB の行フォーマットによって上限が異なる）に引っかかってエラーになることがあります。WordPress のコアテーブルが meta_key(191) のように先頭191文字だけのインデックスを使っているのは、この制限への対策です。
文字化けしたデータが入っている状態で変換すると、化けた文字がそのまま新しい文字コードに変換されてしまいます。文字化けの修復は別の手順になるため、変換前に SELECT で日本語が正しく表示されることを確かめてください。
よくあるエラーと対処
Illegal mix of collations
Illegal mix of collations (utf8mb4_0900_ai_ci,IMPLICIT) and (utf8mb4_unicode_520_ci,IMPLICIT) for operation '=' のようなエラーは、Collation の異なる列どうしを比較・結合したときに出ます。根本的な対処はテーブルの Collation をそろえることです。急ぎの場合は、クエリの片側に COLLATE utf8mb4_unicode_520_ci を付けて比較規則を合わせる方法もありますが、インデックスが使われなくなることがあるため、恒久対策にはしないでください。
Unknown collation: 'utf8mb4_0900_ai_ci'
MySQL 8.0 で書き出したダンプを、MariaDB や MySQL 5.7 に読み込んだときに出るエラーです。移行先にその Collation が存在しないことが原因です。移行先のバージョンを上げるか、ダンプ内の Collation 指定を移行先にあるものへ置き換えてから読み込みます。
まとめ
- 文字コードと Collation はサーバー・データベース・テーブル・列・接続の階層ごとにあり、最終的に効くのは列の設定です
- 文字コードは
utf8mb4を選びます。utf8は3バイトまでのutf8mb3の別名です - Collation は「何を同じ文字とみなすか」の規則です。日本語では濁点やかなの違いが無視される場合があるため、実際の環境で比較結果を確かめます
- 現状の確認は
SHOW VARIABLESとinformation_schemaで行います - 既定値は
my.cnf、WordPress の接続とテーブル作成はDB_CHARSETとDB_COLLATEで決まります。既存のテーブルを変えるには ALTER 文が必要で、バックアップとステージングでの確認が前提です