Auf den Punkt gebracht, im Slogan: Man lässt sich ja was sagen …
http://wordpress.stackexchange.com/questions/169013/reset-reorder-posts-id-in-the-mysql-wp-posts-table
Die Einsicht war die kleine Mühe von Übersetzung (Google) und Darstellung Wert! – der Blog geht von der Frage ähnlichen Ausgangspunkts (s. Arbeitsablauf iPad mini betreffs IDs) und führt threads zur Erkenntnis wie Antwort der Fragestellung: Sich erübrigte IDs löschen und bestehende IDs neu anordnen?
Reset/Reorder posts ID in the MySQL wp_posts table
ID in der MySQL wp_posts Tabelle zurücksetzen / neu anordnen
Fragestellung
Ich habe eine WordPress Website, die sehr beliebt ist. Ich bin in den Prozess der Optimierung der Website vor dem Hinzufügen von anderen Plugins wie das WPML-Plugin, die ich vermute, wird mit benutzerdefinierten Post-Typen. Die Website hat bereits andere Plugins, die ich nicht vermute, verwenden Sie die wp_posts Tabelle für benutzerdefinierte Post-Typen außer für 1 oder 2 nur zu erstellen.
Ist es möglich, die ID-Spalte in der Tabelle wp_posts neu zu erstellen / neu zuzuordnen / neu anzuordnen, so dass die Post-IDs von 1 beginnen und ohne Lücken zunehmen.
Die Tabelle wp_posts enthält 3.349 Zeilen. Die Seite enthält rund 412 Beiträge (Post-Typ) in der WordPress wp_posts Tabelle. Die größte Zahl in der ID-Spalte ist 7060 (das ist sehr groß) und jeder neue Beitrag, den ich addiere, erhöht die Zahl auf 7061. Der Rest der Zeilen in der Tabelle sind andere Post-Typen wie Anhänge, von denen einige von alten erstellt wurden Plugins. Es gibt 2.786 Zeilen für die Anlage Post-Typ, die eine sehr große Zahl … Die 412 Beiträge enthalten alle Informationen, die für die Website benötigt werden. Ich konvertiere die Bilder in Inline SVG und Latex. Die meisten Bilder waren Zahlen. Also nach all dem werde ich wohl 412 Zeilen in der Tabelle wp_posts haben.
Ich weiß, ich könnte die AUTO_INCREMENT zurück auf 1 zurücksetzen; ALTER TABLE tablename AUTO_INCREMENT = value;
Aber ich bin mir nicht sicher, wie man die Post-IDs neu anordnet. Ich möchte sehen, welche Vorsichtsmaßnahmen ich mir vorher bewusst sein sollte, bevor ich das versuche. Ich denke, das ist wichtig, um die Post-IDs zu vereinfachen, weil sie überall auf der Multi-Website verwendet werden. Wenn es eine Lösung gibt, die die gesamten Verweise auf die Beiträge über andere Tabellen neu ordnen und aktualisieren könnte, wäre das großartig !.
Ich bin mir bewusst, dass dies eine MySQL-Funktion ist und ich muss mit AUTO_INCREMENT arbeiten.
Ich bin mir bewusst, dass andere Post-Typen wie Anhänge eine übergeordnete ID enthalten können, die mit den ursprünglichen Posts verknüpft ist. Ich bin nicht so besorgt über Anhänge, weil ich die 2.786 Anhänge trotzdem loswerden will.
Ich werde wahrscheinlich die Tags und Kategorien verlieren, aber die Vereinfachung der Post-IDs ist wichtig. Ich werde die Tags und Kategorien sowieso wieder aufbauen. Gibt es einen ordentlichen Weg, um diese geheftet zu halten.
Gibt es irgendwelche anderen Gefahren, um die ich mir Sorgen machen sollte? Weil viele Skripte / Features um die Hauptaufstellungsort-Aufstellungsorte gebaut werden, möchte ich die Post-IDs so einzigartig wie möglich an diesem Punkt machen. Eine Lücke von 100s zu haben ist für mich nicht einzigartig.
Ich hoffe, jemand hat die perfekte Lösung dafür. Bin ich eine sehr gefährliche Idee?
Antwort zur Fragestellung (Dialog)
1
Ich habe viele Websites mit viel mehr als 7000 Beiträge gesehen, ich bezweifle sehr, dass Sie die Leistungssteigerungen erhalten, die Sie davon erwarten, dies zu tun, und denken Sie daran, dass Sie alle Post-Meta-Tabellen, den Begriff Beziehungen, alle Optionen, die Post-IDs speichern, löschen Sie alle Ihre Objekt-Caches, Transienten und alle URLs, die Post-IDs enthalten, werden nicht mehr funktionieren oder an der falschen Position führen. Ihre Post-IDs sind so einzigartig wie sie jemals sein werden, eine Lücke ändert sich nicht (und Lücken werden passieren, sobald ein Beitrag sowieso gelöscht wird). Ich vermute Mikro-Optimierung.
Tom J Nowell, 20. November um 15:29
Antwort vom Fragesteller (Dialog)
Die neueste ID ist zu groß (7060), die auf 412 reduziert werden könnte. Ich habe ein Feature über die gesamte Website, wo meine Abonnenten werden ständig mit dem Post ids, um Beiträge als Artikel zu „Dokumente“ und andere Elemente innerhalb der Website mit einer App. Dies wird passieren, so dass mit kleineren Zahlen wird es leichter zu erinnern. Kann ich WordPress nicht dazu benutzen, unbenutzte IDs zu verwenden? Ich versuche nicht nur, für die Leistung zu optimieren, sondern um den Tisch ordentlich zu machen, bevor ich vorankomme.
user3072613, Nov 20 ’14 um 21:58 Uhr
Antwort zur Fragestellung (Dialog)
2
Das sind keine kleinen Zahlen, 2 Faktor-Auth-Nummern, die von Google und Banken verwendet werden, sind 6 Ziffern, und die Wissenschaft sagt, dass wir zwischen 5 und 7 Ziffern in unserem Kopf gut halten können. Was Sie tatsächlich haben, ist eine Usability-Problem, so dass Ihre Benutzer erinnern Zahlen ist eine schreckliche, schreckliche Idee, und wird nicht skalieren. Was passiert, wenn du 9.999 Beiträge hast? Egal, was Sie versuchen zu tun erfordert eine Menge von MySQL-Kenntnisse, würden Sie besser dran fragen, wie man eine richtige Benutzeroberfläche mit einem Dropdown oder ein Autovervollständigung, um einen Beitrag zu wählen, anstatt mit der Kopie einfügen ein Nummernschema.
Tom J Nowell, Nov 21 ’14 um 0:53 Uhr
Antwort zur Fragestellung (Dialog)
@TomJNowell ist absolut richtig. Das System, das du implementiert hast, ist schrecklich. Darüber hinaus, auch wenn du diese Änderungen machen würdest, musst du dich immer wieder wöchentlich, sogar täglich, bauen. Das ist lächerlich. Ich würde argumentieren, dass Sie versuchen, die Datenbank in einer sehr datenbankähnlichen Weise zu arbeiten. Dies ist nicht einmal ein WordPress-Problem so viel wie ein Datenspeicher / Datenintegrität Problem. Sie fahren ein Auto von der Brücke und ins Wasser und fragen uns dann, wie man es schwimmt.
s_ha_dum Nov 27 ’15 um 15:03 Uhr
Antwort zur Fragestellung
Wenn Sie fortlaufende Nummern für Ihre Beiträge wünschen, dann verwenden Sie nicht die Post-ID-Spalte.
AUTO_INCREMENT soll eindeutige Zahlen (und Split-Gehirne in Multi-Master-Replikation) bereitstellen, es wird niemals ohne Lücken sein, vor allem nicht in WordPress (Revisionen, Autosaves, Seiten, Kontaktformulare, Galerien und eine Reihe anderer Plugins) Und vor allem nicht bei InnoDB. Ein einfacher Transaktionsfehler / Roll-back kann dazu führen, dass die AUTO_INCREMENT-Felder eine Milliarde Mal erhöhen, ohne eine einzelne Zeile einzufügen, es ist ziemlich normales Verhalten. Ich werde auch Tamas aus diesem Stack Overflow Thread zitieren:
„Sie sollten niemals von den numerischen Merkmalen der autogenen Schlüssel abgehen“.
Aus Performance-Sicht ist es nicht wichtig. Ein BIGINT-Holding 412, ein BIGINT-Holding 7060 und ein BIGINT mit fünf Milliarden sind alle 64-Bit-Integer.
Wenn du wirklich sequenzielle Identifikatoren wünschst (für deine UX oder was auch immer) solltest du dein eigenes viel vorhersehbarer und isolierter Numerierungslogik verwenden.
kovshenin, Apr 3 ’16 at 10:55
Antwort zur Fragestellung (Dialog)
Diese Post-ID wird verwendet, um Daten über viele verschiedene Tabellen durch den WordPress Core zu vernetzen, plus was auch immer Plugins tun könnte oder was auch immer das Thema tun könnte. Es gibt auch Potenzial, Links zu brechen, wenn deine Website jemals benutzt hat? P = Permalinks. Also ja, das ist eine sehr gefährliche Idee.
Um deine Post-IDs richtig zurückzusetzen, wirst du für eine Menge Arbeit sein, aber diese Arbeit würde verschwendet werden. WordPress verwendet ein unsigniertes BIGINT für dieses Feld, das zu einer Obergrenze von 18.446.744.073.709.551.615 fähig ist. Du wirst niemals dorthin kommen, mit oder ohne die „Lücken“ zwischen den Posten.
Zusätzlich, jedes Mal, wenn WordPress einen Datenbankeintrag macht, musst du die Arbeit wiederholen – da WordPress keine Anstrengungen unternimmt, die IDs ordentlich zu halten, wie du scheinst (irrtümlich) denkst – ist notwendig. Also jedes Mal, wenn WordPress die Datenbank modifiziert, wirst du es neu reparieren lassen. Das ist eine Menge Code zu schreiben, um das System in Platz zu setzen, und eine Menge CPU-Zeit, um es zu laufen.
s_ha_dum, Nov 20 ’14 at 20:38
Antwort vom Fragesteller (Dialog)
Ich versuche zu verstehen, wie viel diese Arbeit ist. Ich denke, es ist nicht so viel. Ich interessiere mich nicht für WordPress Attachments mehr (SVG ist besser). So könnte ich einfach alle Anhänge löschen (die Zeilen um mehr als die Hälfte reduzieren). Ich bin dabei, die Tags und die Kategorie mit einer besseren Hierarchie wieder aufzubauen, so dass die Kategorien und Tags nicht so wichtig sind. Die meisten Plugins sind beliebte Plugins wie: WP zu Twitter, WP Statistics, WP User Frontend Pro, WordPress SEO, W3 Total Cache. Sicherlich konnte ich ein Skript schreiben, das die Ionen ab dem 1 wiederherstellen konnte, während das Aktualisieren aller ID verwendet wurde.
… in jeder Tabelle in der Datenbank Wie würde ich MySQL zwingen, die IDs zurückzusetzen, um von 1 zu starten und auf 412 zu erhöhen?
user3072613, Nov 20 ’14 um 22:23 Uhr
Antwort für Fragesteller (Dialog)
Es ist eine Menge Arbeit, die wiederholt werden muss, immer wenn ein Beitrag, Revision oder Mediendatei gelöscht wird, ohne Garantie wird es narrensicher sein.
Tom J Nowell, Nov 21 ’14 um 0:55
Antwort zur Fragestellung
Wenn das einzige, was Sie interessieren, sind die Beiträge, dann können Sie die Beiträge exportieren und importieren sie in eine neue DB. Ich bin mir nicht sicher, ob der eingebaute Exporteur die Post-IDs und Anhänge hierfür speichert, die Sie am Ende brauchen, um Ihre eigenen zu schreiben, was, wenn Sie nur über Post-Inhalte kümmern sollten nicht zu hart sein.
Das Problem ist, dass Sie nicht wirklich eine interne Software-ID als externe Kennung verwenden, ist es nur schlecht für Ihre Gesundheit. Wenn Sie eine einzigartige leicht zu merken Identifikator haben müssen, erstellen Sie einfach eigene Meta-Feld und verwenden Sie es dafür.
Mark Kaplun, 22.11.2010 um 17:07 Uhr
Fazit aus diesem Thread: Was abgebissen wurde, kann man nicht mehr rückgängig machen ↑