特定の状況下では、wp_options (または他のテーブル) がプライマリキーのインデックスを失うことがあります。
この問題の正確な原因は 100% 明確ではありません。データベースをあるデータベースから別のデータベースに手動で移行したか、異なる MySQL バージョンや InnoDB / MyISAM のような型などのすべての構成をカバーしていない Plugin やツールを使用した場合に発生し得るようです。
念のため: WP STAGING はこのエラーの原因ではありません。これが発生したときに、管理ダッシュボードに目立つ警告を表示することで、エラーの検出をお手伝いするだけです。
これを行うのは、このエラーが重大で非常に陰湿なものだからです。すぐに解決できないほど手遅れになるまで気付かないことがあります。修正を待つ時間が長くなるほど、解決が難しくなります。
その理由は、サイトが以前とほぼ同じように動作し、内部でだけ違った動きをするためです。
wp_options テーブルでなぜこれが重要なのか、簡単な例を挙げます:
wp_options テーブルには option_id という列名があります。この ID は通常一意で、1 つの行にのみ割り当てられます。ID は各行に対して自動的にインクリメントされ、次のようになります:
option_id | option_name
1 | option1
2 | option2
3 | option3
プライマリキーが欠落していると、option_id がインクリメントされなくなり、すべての新しい行は option_id 番号 0 を取得し、次のようになります:
option_id | option_name
1 | option1
2 | option2
3 | option3
0 | option4
0 | option5
0 | option6
問題は、これらの行を別のデータベースにエクスポートしてインポートしようとしたときに発生します。option_id は一意の番号でなければならないため、「Can not insert duplicate key …」のような SQL 挿入エラーが表示され、移行が停止します。
その結果、WP STAGING や他の移行 Plugin は別のデータベースへのデータベースデータ転送を実行できません。たとえば、Staging サイトから本番サイトへの PUSH 処理が失敗します。
こちらのスクリーンショットは、option_id 列にプライマリキーが設定された通常の wp_options テーブルを示しています:

こちらの 2 つ目のスクリーンショットは、プライマリキーが欠落した wp_options テーブルを示しています:

注: このチュートリアルでは、たとえば「adminer」や phpMyAdmin などのデータベース管理ツールが必要です。
既存の option_id をリネームする
- データベース全体を Backup してダウンロードしてください。
- 重複しているすべての ID について option_id の値を変更してください。
option_id 列で最大の番号を取得し、1 つずつ増やすことをおすすめします。このスクリーンキャストでその方法を示します:
プライマリキーインデックスを追加してテーブルを変更する
- phpMyAdmin または adminer を開き、wp_options テーブルに移動してください。
- このスクリーンショットのように「alter indexes」をクリックしてください:

- 次に「option_id」をプライマリキーとして設定してください:

- 「Duplicate entry ‘0’ for key PRIMARY」というエラーが表示された場合、テーブルにまだ重複する ID があり、すべてを変更していないことを意味します:

- その場合は、残りを見つけて値をカウントアップし、テーブル内に重複がないようにしてください。その後、テーブルへの PRIMARY KEY の追加を再度試みることができます。
欠落したプライマリキーを修正した後、Staging サイトを本番サイトに PUSH する準備ができますが、データベースを Backup することをおすすめします。