ローカルと本番の投稿ID、今からでも揃えられるか検証した話

ローカルと本番で投稿IDがズレてた話を書いたあと、「今からでも揃えられるの?」と聞かれました。
結論を先に言うと、次の1件だけなら技術的には揃えられます。
でも実際に今日の数字を見たら、揃えたところで意味がないことがよく分かりました。

まず現在の数字を見てみる

ローカルと本番、それぞれのwp_postsテーブルで一番大きいIDを調べてみました。
削除や欠番がなければ、次に新しく作られる投稿はこの数字の続きになるはずです。

wp eval 'global $wpdb; echo $wpdb->get_var("SELECT MAX(ID) FROM wp_posts");'
# ローカル: 865(次はおそらく866)
# 本番:     794(次はおそらく795)

差は71。
意外と開いていました。
これだけ離れていると、単純に片方をもう片方に合わせるだけでは済みません。

次の1件だけなら、実は揃えられる

wp_postsテーブルのAUTO_INCREMENTは、後から大きい値に書き換えられます(小さくは戻せません)。

-- 実行前に必ずDBのバックアップを取り、テーブル接頭辞(wp_の部分)が
-- 実際の環境と合っているか確認してからアクセスの少ない時間帯に実行する
ALTER TABLE wp_posts AUTO_INCREMENT = 866;

本番でこれを実行すれば、そのあと最初にwp_postsへ書き込まれるレコードは866番になります。
ただし「最初に書き込まれるレコード」が、狙った記事本体になるとは限りません。
新規投稿画面を開いただけでもレコードは増えるので、そこに先に866番を取られてしまう可能性もあります。
うまく行っても、揃うのは1件だけです。

今日書いた2記事で、もう証拠が出ていた

ここで、今日実際に作業した記録を見返してみました。
今日はブログを2本、ローカル→本番の順で同じ手順(記事作成→アイキャッチ登録)で公開しています。
そのときに振られたIDを、両方のDBから直接引いてみました。

-- ローカル(858〜865)
858 | revision   | 1記事目の下書きリビジョン
859 | post       | 1記事目の本体
860 | revision   | 1記事目の下書きリビジョン
861 | attachment | 1記事目のアイキャッチ
862 | post       | 2記事目の本体
863 | revision   | 2記事目の下書きリビジョン
864 | attachment | 2記事目のアイキャッチ
865 | revision   | 1記事目の下書きリビジョン(あとから追加)

-- 本番(786〜794)
786 | revision    | (前の記事のリビジョン)
787 | post        | auto-draft(自動下書き、中身なし)
788 | post        | 1記事目の本体
789 | revision    | 1記事目の下書きリビジョン
790 | attachment  | 1記事目のアイキャッチ
791 | post        | 2記事目の本体
792 | revision    | 2記事目の下書きリビジョン
793 | attachment  | 2記事目のアイキャッチ
794 | revision    | 1記事目の下書きリビジョン(あとから追加)

本番側にだけ、post_status: auto-draftの投稿が1件挟まっています。
中身は空の「自動下書き」で、おそらく以前に本番のwp-adminで新規投稿画面を開いた(そして保存せず離れた)ときに、WordPressが自動で作ったものです。
このタイミングでは記事の内容も操作手順もローカルとまったく同じだったのに、この1件のせいで本番側だけIDが1つ余分に進んでいました。

revisionの数も、実は揃っていない

もう1つ気になったのが、リビジョンの数です。
1記事目はローカル・本番とも「保存→あとから見出しを1箇所修正」という同じ2回の編集をしたのですが、両方ともリビジョンは2件でした。
ここは偶然揃っていましたが、編集にかけた時間・自動保存が走るタイミング・手動保存の回数は毎回変わるので、次回も揃う保証はありません。

結論: 揃えても、揃った状態は1件しか持たない

整理すると、こうなります。

• ALTER TABLE ... AUTO_INCREMENTで、次の1件だけは狙った番号に揃えられる
• ただしauto-draftやリビジョン、添付ファイルなど、記事本体以外のレコードでもIDは消費される
• 増えるタイミングも本数も、ローカルと本番で一致する保証がない
• つまり2件目以降は、また勝手にズレていく

今日のように、まったく同じ手順で2記事続けて公開しても同じでした。
本番側にだけ余計なauto-draftが挟まっていました。
「今から揃える」という作業自体に、ほとんど意味がないことがこれで裏付けられたと思います。

まとめ

結局、答えは元記事のときと同じでした。
IDを揃える努力をするより、スラッグや投稿タイトルなど、環境をまたいでも変わらない値で紐づける設計にする方が早いです。
今回は「本当に無理なのか」を数字で確かめられたので、以前より納得して次に進めそうです。