wp_posts-Tabelle: Entfernen Sie nicht benötigte Spalten, um den databasespeicher zu sichern

Ich suche auf Google nach, aber habe nichts gefunden. Ich möchte die unbenutzten Spalten meiner WordPress wp_posts Tabelle entfernen, um meinen databasespeicher zu speichern …

Ich weiß, wenn die Tabellenspalte leer ist, wird es keinen Einfluss auf meinen Platz haben, aber die gepflegte Tabelle kann meine Website-Performance erhöhen !!!, derzeit 23 columns in meiner wp_posts-Tabelle …

Ich habe 1,200,000 Rows in meiner Tabelle wp_posts mit der Größe: 1.2 GB , und es wird in 2 Monaten auf 30,000,000 Rows erhöhen …

Es gibt viele Felder, die ich nicht benutze, also wie kann ich sie löschen, so dass es keine Auswirkungen auf mein WP-Projekt hat?

Ich mache mir Sorgen, wenn ich eine Spalte lösche, kann meine Website auf keiner Stufe funktionieren.

Spalten, die ich löschen möchte:

 post_date post_date_gmt ping_status post_password to_ping pinged post_content_filtered //more if possible, i will update my posts, but i dont need last modify date. post_modified post_modified_gmt 

Bildbeschreibung hier eingeben

Danke im Voraus 🙂

Solutions Collecting From Web of "wp_posts-Tabelle: Entfernen Sie nicht benötigte Spalten, um den databasespeicher zu sichern"

Wenn Sie die DB-Struktur ändern, als Sie effektiv WordPress nicht mehr ausführen, aber Ihre Gabelung davon. Dies ist nicht immer eine negative Sache zu tun, solange Sie wissen, dass, sobald Sie es tun, es keine Garantie gibt, dass jedes Plugin oder Thema oder zukünftige WordPress-Version mit Ihrem DB-Schema arbeiten wird.

TL; DR

Sehr schlechte Idee.

Das Löschen der Spalten hat keine großen Auswirkungen auf die Tabellengröße. Es wird jedoch die regulären WordPress-Abfragen unterbrechen, da die SQL-Schreib- und Leseabfragen auf diese Spalten verweisen. Wenn sie nicht vorhanden sind, wird die SQL ungültig und Sie erhalten nur einen MySQL-Fehler, nicht die Ergebnisse.

1,2 GB ist nicht so viel. Eine normale InnoDB-Tabelle kann bis zu 64 TB enthalten :

Die maximale Tablespace-Größe beträgt vier Milliarden databaseseiten (64 TB). Dies ist auch die maximale Größe für eine Tabelle.

Ihre Indizes könnten ein Problem sein. Hier ist eine gute Erklärung, wie man sie analysiert: Wie berechnet man eine bestimmte InnoDB-Indexgröße?

Möglicherweise möchten Sie die Indexerstellung während des Imports deaktivieren oder die vorhandene vollständig ändern.

Eine weitere Option ist die Partitionierung , bei der mehrere physische Tabellen verwendet werden, die nur logisch aussehen. Nicht sicher, wie WordPress damit umgehen kann, da es einige Einschränkungen gibt .

Oder überlegen Sie, eine vollständig separate Tabelle für Ihre Daten zu verwenden. Diese in die regulären Abfragen zu ziehen ist nicht so schwer. Es gibt viele Filter, um databaseabfragen zu ändern, Sie werden wahrscheinlich eine finden, die Ihren Bedürfnissen entspricht.

habe 1.200.000 Zeilen in meiner wp_posts-Tabelle mit der Größe: 1,2 GB, und es wird in 2 Monaten auf 30.000.000 Zeilen steigen …

Es ist total verrückt. Ich weiß wirklich nicht, was der Grund dafür ist, aber 30 MILLION Posts sind verrückt. Du musst wirklich gehen und dich hinsetzen und darüber nachdenken, was du tust und was dein Ziel ist, und um wirklich ehrlich und direkt hier zu sein, hast du hier ein paar falsche Gefängnisse.

Ich weiß wirklich nicht, ob jede Art von durchschnittlich gekauften Hosting jemals genug Ressourcen haben wird, um eine Website mit einer db übermäßig massiv zu betreiben. Haben Sie Ihren eigenen Super-Server, auf dem Sie das ausführen?

Einfaches Löschen von Tabellen und Spalten, die mit WordPress erstellt wurden, ist hier definitiv keine Option. Das Löschen nicht verwendeter Spalten und Tabellen wird Ihre performance auf der Website nicht wesentlich verbessern. Meinst du vielleicht ein paar andere Sachen, die dich dazu bringen, deinen Kopf gegen einen Berg zu stoßen?

LÖSUNG

Überdenken Sie Ihren kompletten Plan mit Ihrer Website und stoppen Sie alle Wahnsinn 😉

Zusätzlich zu dem, was alle anderen erwähnt haben, sind Ihre Absichten errorshaft – wenn Sie versuchen, Platz zu sparen, ist dies nicht der richtige Weg.

  • post_date – 8 Bytes
  • post_date_gmt – 8 Bytes
  • ping_status – 8 Bytes (höchstens – open , closed oder inherit )
  • post_modified – 8 Bytes
  • post_modified_gmt – 8 Bytes

Die anderen genannten Felder sind wahrscheinlich 0 Bytes (Pings in Einstellungen> Diskussion ausschalten).

40 Byte pro Zeile * 1,2 Millionen Zeilen = ~ 40 MB = ~ 3,5% von 1,2 GB

Mit anderen Worten, Ihre Ersparnisse sind so trivial, dass es den Aufwand der Implementierung einfach nicht wert ist (was zumindest sehr mühsam wäre).

Wenn Sie so viele Beiträge in einer Installation möchten, ist ein besseres Hosting die Antwort.