MySQL wp_postsテーブル内の投稿IDのリセット/並べ替え
私はかなり人気のあるWordpressのサイトを持っています。カスタム投稿タイプを使用すると思われるWPMLプラグインなどの他のプラグインを追加する前に、サイトを最適化しています。このサイトにはすでに他のプラグインがありますが、それらを作成するためだけに1または2を除いてカスタム投稿タイプにwp_postsテーブルを使用するのではないかと思います。
wp_postsテーブルのID列を再構築/更新/並べ替えして、投稿IDが1から始まり隙間なく増加するようにすることは可能ですか？
Wp_postsテーブルには、3,349行が含まれています。このサイトのwordpress wp_postsテーブルには、約412の投稿（投稿タイプ）が含まれています。 ID列の最大数は7060（これは非常に大きい）です。追加する新しい投稿は7061に増えます。表の残りの行は添付ファイルなど他の投稿タイプで、一部は古いユーザーによって作成されたものです。プラグイン添付ファイルの投稿タイプには2,786行あります。これは、これらの添付ファイルを使用しないことを考えると非常に大きな数です。 412の投稿には、サイトに必要なすべての情報が含まれています。画像をインラインSVGとラテックスに変換しています。ほとんどの画像は数字でした。それで、結局のところ、私はおそらくwp_postsテーブルに412行あるでしょう。
を使用してAUTO_INCREMENTを1にリセットできることを知っています。 ALTER TABLEテーブル名AUTO_INCREMENT =値。
しかし、投稿IDを並べ替える方法がわかりません。これを試す前に注意すべきことを確認したいと思います。 Post IDはMultiサイト全体で使用されるため、これはPost IDを単純化するために重要であると思います。他のテーブルにある投稿への参照全体を並べ替えたり更新したりすることができる解決策があれば、それは素晴らしいことです。
私はこれがMySQLの機能であることを認識しており、AUTO_INCREMENTを使用しなければなりません。
添付ファイルなどの他の投稿タイプには、元の投稿にリンクしている親IDが含まれる可能性があることを認識しています。私はとにかく2,786の添付ファイルを取り除きたいので、添付ファイルについてはそれほど心配していません。
私はおそらくタグとカテゴリを失うでしょうが、投稿IDを単純化することは重要です。とにかくタグとカテゴリを再構築します。これらの問題を解決するためのきちんとした方法はありますか。
他に心配しなければならない危険はありますか？多くのスクリプト/機能がメインサイトの投稿を中心に構築されるため、この時点で投稿IDをできるだけ一意にしたいと思います。 100のギャップを持つことは私にとってユニークではありません。
誰かがこれに完璧な解決策を持っているといいのですが。私は非常に危険な考えを試みていますか？
投稿に連番が必要な場合は、投稿ID列を使用しないでください。
AUTO_INCREMENTはユニークな番号（そしてマルチマスターレプリケーションでの分割ブレイン）を提供することを意図しています、特にWordPress（リビジョン、自動保存、ページ、連絡フォーム、ギャラリー、その他のプラグインの束）では、ギャップなしにはなりません。特にInnoDBではそうではありません。単純なトランザクションの失敗/ロールバックにより、単一行を挿入せずにAUTO_INCREMENTフィールドが10億倍に増加する可能性があります。これは非常に正常な動作です。私はまた この スタックオーバーフロースレッドからTamasを引用します。
あなたは、自動生成されたキーの数字の機能に決して頼るべきではありません。
パフォーマンスの観点からは、それは重要ではありません。 412を保持するBIGINT、7060を保持するBIGINT、および50億を保持するBIGINTは、すべて64ビット整数です。
あなたが本当にあなたのUXのためのものであれ何でものようなシーケンシャルな識別子が欲しいなら、あなたはあなた自身のはるかに予測可能で独立した番号付け論理を使うべきです。
この投稿IDは、WordPress Coreによってさまざまなテーブルにまたがってデータをクロスリンクするために使用されます。さらに、プラグインが実行しても、テーマが実行してもかまいません。あなたのサイトが?p=パーマリンクをこれまでに使ったことがあるならば、リンクを解除する可能性もあります。そう、これは非常に危険な考えです。
あなたの投稿IDを正しくリセットするためには、たくさんの仕事をすることになるでしょうが、その仕事は無駄になるでしょう。 WordPressは、 上限18,446,744,073,709,551,615 が可能な 符号なしBIGINTをそのフィールド に使用します。投稿間の「ギャップ」の有無にかかわらず、あなたはそこにたどり着くことは決してないでしょう。
さらに、WordPressがデータベースエントリを作成するたびに、（誤って）必要だと考えているように、WordPressがIDを整理するための努力をしないため、作業をやり直す必要があります。だからWordPressがデータベースを修正するたびに、あなたはそれを再クリーンアップすることになるでしょう。それはシステムを設置するために書くべきたくさんのコードと、それを実行するためのたくさんのCPU時間です。
あなたが気にしているのが投稿だけなのであれば、投稿をエクスポートしてそれらを新しいDBにインポートすることができます。内蔵のエクスポーターに投稿IDとその添付ファイルが保存されているかどうかはわかりませんが、投稿内容だけに関心がある場合はそれほど難しいことではありません。
問題は、内部のソフトウェアIDを外部の識別子として使うべきではないということです。それはあなたの健康にとって悪いことです。覚えやすいユニークな識別子が必要な場合は、自分でメタフィールドを作成してそれを使用してください。