WordPressデータベース統合の深淵：ID衝突を排し、整合性を担保する物理的移行戦略
WordPressのデータベーススキーマは、15年以上前の設計思想を色濃く残した、ある種「呪われた遺産」である。特に`wp_posts`と`wp_postmeta`の1対多のリレーションは、外部キー制約（Foreign Key Constraints）をあえて放棄したMyISAM時代の名残を今も引きずっている。
複数のインスタンスを統合する際、単なるSQLダンプのインポートは、論理的破綻への最短経路だ。本稿では、シニアアーキテクトの視点から、ID空間の物理的分離と、メタデータ整合性を維持するための「脱・単純エクスポート」の手法を解説する。
—
1. ID空間の物理的衝突：なぜ自動増分(AI)が裏切るのか
MySQLの`AUTO_INCREMENT`は、テーブル単体での一意性は保証するが、分散環境における「意味論的な一意性」を担保しない。
複数のWordPressサイトを統合する場合、`wp_posts.ID`はPRIMARY KEYであると同時に、`wp_postmeta.post_id`のインデックスとして機能する。移行元Aと移行元Bで同じIDが存在する場合、メタデータの結合は即座に崩壊する。
解決の核心：
単純な `INSERT INTO … SELECT` は避けるべきだ。`post_id`を再計算するための「マッピングテーブル」を作成し、参照整合性をアプリケーションレイヤーで再構築する「2段階移行」が唯一の正解となる。
—
2. 再マッピングのアーキテクチャ
以下のプロセスは、メモリ効率を考慮し、バッチ処理で実行されることを想定している。
ステップ1：マッピングテーブルの生成
移行元テーブルと移行先テーブルの間で、IDの変換表を作成する。
— マッピングテーブルの構築
CREATE TABLE wp_id_map (
old_id BIGINT UNSIGNED NOT NULL,
new_id BIGINT UNSIGNED NOT NULL,
type VARCHAR(20), — ‘post’, ‘comment’, ‘user’
PRIMARY KEY (old_id, type)
) ENGINE=InnoDB;
ステップ2：再帰的整合性インジェクション（コード例）
単純なSQLでは不可能な場合、PHP側で`wp_insert_post()`を叩くのは非効率だ。`$wpdb`を直接操作し、アトミックに移行する。
/
- 伝説的移行ルーチン：wp_postsの統合とメタデータの再帰的結合
/
function migrate_posts_with_integrity($old_wpdb, $new_wpdb) {
// トランザクションで囲み、整合性を保証
$new_wpdb->query(‘START TRANSACTION’);
$posts = $old_wpdb->get_results(“SELECT FROM {$old_wpdb->prefix}posts”);
foreach ($posts as $post) {
// IDを強制的にNULL指定することで、自動増分を誘発させつつ、
// 旧IDを記録する
$old_id = $post->ID;
$post_data = (array)$post;
unset($post_data[‘ID’]);
$new_wpdb->insert(“{$new_wpdb->prefix}posts”, $post_data);
$new_id = $new_wpdb->insert_id;
// マッピングテーブルに保存
$new_wpdb->insert(‘wp_id_map’, [‘old_id’ => $old_id, ‘new_id’ => $new_id, ‘type’ => ‘post’]);
// メタデータの移行
migrate_postmeta($old_id, $new_id, $old_wpdb, $new_wpdb);
}
$new_wpdb->query(‘COMMIT’);
}
—
3. メタデータ移行の罠と最適化戦略
`wp_postmeta`は巨大なEAV(Entity-Attribute-Value)モデルだ。ここでのボトルネックは、単一クエリのコストではなく、インデックスの更新コストにある。
- インデックスの無効化: 数百万行の移行を行う場合、`wp_postmeta`の`post_id`インデックスを一時的に削除（DROP）し、移行後に再構築する方が、B-Treeの再平衡化コストを抑えられる。
- バルクインサートの活用: 1行ずつの挿入は、`log_bin`（バイナリログ）の肥大化とフラグメンテーションを引き起こす。`INSERT … VALUES (…), (…), (…)` の形式で、500行単位のチャンクに分割し、メモリ使用量を最適化すべきだ。
—
4. 盲点：GUIDと内部リンクの破壊
IDが変更されると、`wp_posts.guid`も修正が必要になる。さらに過酷なのは、`post_content`内にハードコードされた絶対パスや、ショートコード内のID指定だ。
これらはデータベースレベルの移行だけでは解決できない。移行後、以下の正規表現による一括置換を検討せよ。
— 内部リンクの置換（シリアライズデータの破損に注意）
— シリアライズされたデータが含まれる場合は、wp-cliの search-replace を利用すること
UPDATE wp_posts
SET post_content = REPLACE(post_content, ‘old-domain.com’, ‘new-domain.com’);
—
終わりに：神は細部に宿る
WordPressのデータベース移行を成功させる秘訣は、「システムを信頼しないこと」にある。
1. 整合性チェック: 移行前後の `SELECT COUNT() FROM wp_posts` だけでなく、メタデータの欠落をチェックするクロス集計を必ず実行すること。
2. 実行ログの可視化: `wp_id_map`テーブルは、移行後のトラブルシューティングにおいて、旧IDから新IDを追跡する唯一のライフラインとなる。
データベースはシステムの心臓だ。心臓移植を行う外科医のように、執拗なまでの正確さと、失敗を許容しない防御的コードで挑んでほしい。健闘を祈る。