{"id":2145,"date":"2026-08-23T13:15:54","date_gmt":"2026-08-23T10:15:54","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=2145"},"modified":"2026-10-18T05:20:21","modified_gmt":"2026-10-18T02:20:21","slug":"wordpress-tabelle-wp-postmeta-ist-riesig-ursachen-und-bereinigung","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/de\/wordpress-tabelle-wp-postmeta-ist-riesig-ursachen-und-bereinigung\/","title":{"rendered":"Warum die WordPress-Tabelle wp_postmeta so gro\u00df wird"},"content":{"rendered":"

Ihre wp_postmeta-Tabelle ist gro\u00df, weil einige wenige Meta-Schl\u00fcssel gro\u00df sind. Fast nie liegt es an \u201eWordPress allgemein\u201c, und selten an den verwaisten Zeilen, mit denen viele Anleitungen beginnen. Finden Sie zuerst die Schl\u00fcssel. Die Abfrage dauert eine Sekunde und zeigt Ihnen, ob Sie es mit einem Page-Builder, einem Shop, einer Mediathek oder einem Plugin zu tun haben, das Sie vor zwei Jahren entfernt haben.<\/p>\n

Jeder dieser F\u00e4lle verlangt eine andere Antwort. Nur ein Teil davon ist L\u00f6schen.<\/p>\n

Inhaltsverzeichnis<\/strong><\/p>\n
    \n
  1. Erst messen, dann bereinigen<\/a><\/li>\n
  2. Welche Schl\u00fcssel meist am schwersten sind<\/a><\/li>\n
  3. Verwaiste Zeilen: Metadaten ohne Beitrag<\/a><\/li>\n
  4. Auch Revisionen tragen Metadaten<\/a><\/li>\n
  5. Altlasten entfernter Plugins<\/a><\/li>\n
  6. Einen Schl\u00fcssel l\u00f6schen, ohne Nebenwirkungen<\/a><\/li>\n
  7. Warum die Tabelle auf der Festplatte nicht schrumpft<\/a><\/li>\n
  8. \u00dcberpr\u00fcfung<\/a><\/li>\n
  9. AIOWS Database Cleaner<\/a><\/li>\n
  10. H\u00e4ufige Fragen<\/a><\/li>\n
  11. Quellen<\/a><\/li>\n<\/ol>\n<\/div>\n

    Erst messen, dann bereinigen<\/h2>\n

    Sie brauchen zwei Abfragen, und beide lesen nur. Sie f\u00fchren sie in phpMyAdmin oder Adminer aus. Bei den meisten Hostern \u00f6ffnen Sie phpMyAdmin aus dem Kundenbereich, beim Datenbank-Eintrag Ihrer WordPress-Installation. Dort w\u00e4hlen Sie links Ihre Datenbank, \u00f6ffnen den Reiter SQL<\/strong>, f\u00fcgen die Abfrage ein und klicken auf OK<\/strong>.<\/p>\n

    Pr\u00fcfen Sie zuerst Ihr Tabellenpr\u00e4fix. Es steht als $table_prefix<\/code> in Ihrer wp-config.php<\/code> und ist oft nicht wp_<\/code>. Alle Abfragen hier verwenden wp_<\/code>; setzen Sie Ihr eigenes ein.<\/p>\n

    Wie gro\u00df ist die Tabelle, und wie viel davon ist freier Platz?<\/p>\n

    SELECT table_name,\n       ROUND(data_length \/ 1048576, 1)  AS daten_mb,\n       ROUND(index_length \/ 1048576, 1) AS index_mb,\n       ROUND(data_free \/ 1048576, 1)    AS frei_mb,\n       table_rows\nFROM information_schema.tables\nWHERE table_schema = DATABASE()\n  AND table_name = 'wp_postmeta';<\/code><\/pre>\n
    Bei InnoDB ist table_rows<\/code> eine Sch\u00e4tzung. Nutzen Sie den Wert f\u00fcr die Gr\u00f6\u00dfenordnung, nicht f\u00fcr Ihren Vorher-nachher-Vergleich.<\/p>\n
    Welche Schl\u00fcssel belegen den Platz?<\/p>\n
    SELECT meta_key,\n       COUNT(*)                                    AS zeilen,\n       ROUND(SUM(LENGTH(meta_value)) \/ 1048576, 2) AS wert_mb\nFROM wp_postmeta\nGROUP BY meta_key\nORDER BY wert_mb DESC\nLIMIT 25;<\/code><\/pre>\n
    Notieren Sie sich die ersten f\u00fcnf Schl\u00fcssel mit Zeilenzahl und Gr\u00f6\u00dfe. Am Ende vergleichen Sie damit.<\/p>\n
    Zeigt jede Zeile 0.00, ist auch das eine Antwort: Ihr Platz steckt nicht in wp_postmeta<\/code>. Die kleine Testseite f\u00fcr diesen Artikel hatte 136 Zeilen, und jeder Schl\u00fcssel ergab gerundet 0.00 MB.<\/p>\n
    Welche Schl\u00fcssel meist am schwersten sind<\/h2>\n
    Das Pr\u00e4fix eines Schl\u00fcssels verr\u00e4t Ihnen, wer ihn geschrieben hat. Ein Unterstrich am Anfang blendet ihn in Ihrer Box \u201eBenutzerdefinierte Felder\u201c aus. Er sagt Ihnen nicht, dass der Schl\u00fcssel unwichtig ist.<\/p>\n
    \n\n\n\n\n\n\n\n\n\n\n\n\n
    Schl\u00fcsselmuster<\/th>\nGeschrieben von<\/th>\nInhalt<\/th>\nL\u00f6schen?<\/th>\n<\/tr>\n<\/thead>\n
    _elementor_data<\/code>, _elementor_*<\/code><\/td>\nElementor<\/td>\nDas ganze Seitenlayout als JSON, je Seite und je Revision<\/td>\nNein. Das ist Ihre Seite.<\/td>\n<\/tr>\n
    _wp_attachment_metadata<\/code><\/td>\nWordPress<\/td>\nGr\u00f6\u00dfen und Dateinamen jeder Bildgr\u00f6\u00dfe<\/td>\nNein. Ihre Bilder verlieren ihre Gr\u00f6\u00dfen.<\/td>\n<\/tr>\n
    _oembed_<\/code>, _oembed_time_<\/em><\/code><\/td>\nWordPress<\/td>\nZwischengespeichertes HTML eingebetteter Links<\/td>\nJa. WordPress holt es beim n\u00e4chsten Aufruf neu.<\/td>\n<\/tr>\n
    _edit_lock<\/code>, _edit_last<\/code><\/td>\nWordPress<\/td>\nWer gerade bearbeitet, wer zuletzt bearbeitet hat<\/td>\nEgal, und winzig.<\/td>\n<\/tr>\n
    _yoast_wpseo_<\/code>, rank_math_<\/em><\/code><\/td>\nSEO-Plugins<\/td>\nTitel, Beschreibungen, Bewertungen<\/td>\nNein, solange Sie das Plugin nutzen.<\/td>\n<\/tr>\n
    _price<\/code>, _regular_price<\/code>, _sku<\/code>, _stock<\/code><\/td>\nWooCommerce<\/td>\nProduktdaten<\/td>\nNein.<\/td>\n<\/tr>\n
    _billing_<\/code>, _order_<\/em><\/code>, _customer_ip_address<\/code><\/td>\nWooCommerce, nur bei der alten Bestellspeicherung<\/td>\nBestellungen und Kundendaten<\/td>\nNein. Siehe den Hinweis unten.<\/td>\n<\/tr>\n
    Schl\u00fcssel eines entfernten Plugins<\/td>\ndieses Plugin<\/td>\nseine Einstellungen je Beitrag<\/td>\nErst nach der Pr\u00fcfung unter Altlasten<\/a>.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
    Ist Ihr gr\u00f6\u00dfter Schl\u00fcssel der eines Page-Builders, ist Ihre Tabelle gro\u00df, weil Ihre Seiten gro\u00df sind. L\u00f6schen hilft Ihnen dann nicht, weniger Revisionen vielleicht schon. Steht _oembed_*<\/code> oben, k\u00f6nnen Sie den Cache gefahrlos leeren. Kennen Sie den Schl\u00fcssel nicht, lesen Sie den Abschnitt \u00fcber Altlasten, bevor Sie ihn anfassen.<\/p>\n
    Wo WooCommerce Ihre Bestellungen ablegt, sehen Sie unter WooCommerce<\/strong> \u203a Einstellungen<\/strong> \u203a Erweitert<\/strong> \u203a Funktionen<\/strong>, bei \u201eDatenspeicher f\u00fcr Bestellungen\u201c. Auf der Testseite mit WooCommerce 11.2.1: – mit Speichern als WordPress-Beitr\u00e4ge (alt)<\/strong> schrieb eine Bestellung 25   Zeilen in wp_postmeta<\/code>, sechs davon _billing_*<\/code>; – mit Leistungsstarke Speicherung von Bestellungen<\/strong> schrieb eine neue   Bestellung keine. Ihre Anschrift landete in der Tabelle wc_order_addresses<\/code>.<\/p>\n
    Produkte behalten ihre Meta-Daten in jedem Fall in wp_postmeta<\/code>. Der Wechsel auf die neue Speicherung lie\u00df die Zeilen der alten Bestellung liegen, und WooCommerce f\u00fchrte sie als zu bereinigen.<\/p>\n
    Ein Hinweis f\u00fcr Shops.<\/strong> Speichert Ihr Shop Bestellungen noch als WordPress-Beitr\u00e4ge, halten Zeilen wie _billing_*<\/code> und _customer_ip_address<\/code> Namen, Anschriften und IP-Adressen Ihrer Kunden. Das sind personenbezogene Daten im Sinne der DSGVO. L\u00f6schen Sie sie nicht nebenbei bei einer Bereinigung, und behalten Sie sie nicht l\u00e4nger, als Ihre Aufbewahrungspflichten es verlangen. Diese Entscheidung geh\u00f6rt zu Ihrer Datenschutz- und Buchhaltungspraxis, nicht zur Datenbankpflege.<\/p>\n
    Verwaiste Zeilen: Metadaten ohne Beitrag<\/h2>\n
    Eine verwaiste Zeile hat eine post_id<\/code>, die es in wp_posts<\/code> nicht mehr gibt. WordPress erzeugt solche Zeilen nicht selbst: Wenn Sie einen Beitrag l\u00f6schen, entfernt wp_delete_post()<\/code> seine Metadaten gleich mit. Verwaiste Zeilen stammen aus Beitr\u00e4gen, die jemand per SQL gel\u00f6scht hat, aus abgebrochenen Importen und aus Plugins, die ihre eigenen Beitragstypen falsch l\u00f6schen.<\/p>\n
    Z\u00e4hlen Sie nach, bevor Sie annehmen, dass Sie welche haben:<\/p>\n
    SELECT COUNT(*) AS verwaiste_zeilen,\n       ROUND(SUM(LENGTH(pm.meta_value)) \/ 1048576, 2) AS verwaiste_mb\nFROM wp_postmeta pm\nLEFT JOIN wp_posts p ON p.ID = pm.post_id\nWHERE p.ID IS NULL;<\/code><\/pre>\n
    Sind es ein paar hundert Zeilen und ein Bruchteil eines Megabytes, ist das nicht Ihr Problem. Entfernen Sie sie ruhig, aber kehren Sie dann zu Ihrer Schl\u00fcsselliste zur\u00fcck. Ist es ein gro\u00dfer Teil der Tabelle, haben Sie Ihre Ursache gefunden.<\/p>\n
    Wenn Sie auch die anderen Meta-Tabellen pr\u00fcfen m\u00f6chten, f\u00fchrt Sie verwaiste Metadaten in WordPress sicher finden<\/a> durch alle.<\/p>\n
    Auch Revisionen tragen Metadaten<\/h2>\n
    Jede Revision, die Sie speichern, ist eine Zeile in wp_posts<\/code> mit post_type = 'revision'<\/code>. Page-Builder legen zu vielen dieser Revisionen eine Kopie ihrer Layout-Daten ab. Hat Ihre Seite 60 Revisionen, kann sie 60 Kopien ihres _elementor_data<\/code> mit sich tragen.<\/p>\n
    Z\u00e4hlen Sie je Beitrag, bevor Sie etwas l\u00f6schen:<\/p>\n
    SELECT p.post_parent, COUNT(*) AS revisionen\nFROM wp_posts p\nWHERE p.post_type = 'revision'\nGROUP BY p.post_parent\nORDER BY revisionen DESC\nLIMIT 10;<\/code><\/pre>\n
    L\u00f6schen Sie Revisionen \u00fcber WordPress, ein Plugin oder WP-CLI, nicht mit einem nackten DELETE FROM wp_posts<\/code>. Der WordPress-Weg nimmt ihre Metadaten mit. Der SQL-Weg l\u00e4sst sie als verwaiste Zeilen zur\u00fcck, und Sie stehen wieder im vorigen Abschnitt.<\/p>\n
    Damit die Tabelle nicht weiter w\u00e4chst, begrenzen Sie die Revisionen in Ihrer wp-config.php<\/code>:<\/p>\n
    define( 'WP_POST_REVISIONS', 10 );<\/code><\/pre>\n
    Das ganze Vorgehen finden Sie unter alte WordPress-Beitragsrevisionen sicher bereinigen<\/a>.<\/p>\n
    Altlasten entfernter Plugins<\/h2>\n
    Hier k\u00f6nnen Sie sich wehtun. Ein Schl\u00fcssel, den Sie nicht kennen, sieht nach Abfall aus. Manchmal geh\u00f6rt er zu etwas, das bei Ihnen noch l\u00e4uft: zu einer Theme-Option, einem Snippet in Ihrer functions.php<\/code> oder einem Plugin, dessen Name mit dem Schl\u00fcssel nichts zu tun hat.<\/p>\n
    Bevor Sie einen Schl\u00fcssel l\u00f6schen, kl\u00e4ren Sie drei Dinge:<\/p>\n
      \n
    1. Wer ihn geschrieben hat.<\/strong> Suchen Sie den Namen im installierten Code.    Mit WP-CLI oder Shell-Zugang: grep -r \"ihr_meta_key\" wp-content\/<\/code>. Findet    die Suche in wp-content<\/code> nichts, liest ihn sehr wahrscheinlich nichts    Aktives mehr.<\/li>\n
    2. Dass ihn nichts liest.<\/strong> Ein Treffer in einem Plugin, das Sie nicht mehr    nutzen, ist in Ordnung. Ein Treffer in Ihrem aktiven Theme oder in einem    Must-Use-Plugin hei\u00dft: aufh\u00f6ren.<\/li>\n
    3. Wie viele Beitr\u00e4ge ihn tragen.<\/strong> Ein Schl\u00fcssel an jedem Ihrer Beitr\u00e4ge ist    eine Einstellung. Ein Schl\u00fcssel an zw\u00f6lf Beitr\u00e4gen aus 2019 ist eine    Altlast.<\/li>\n<\/ol>\n
      Ein deaktiviertes Plugin entfernt seine Metadaten nicht. L\u00f6schen Sie es \u00fcber die Plugin-Seite, l\u00e4uft seine Deinstallationsroutine, sofern es eine hat. Viele haben keine.<\/p>\n
      Einen Schl\u00fcssel l\u00f6schen, ohne Nebenwirkungen<\/h2>\n
      Erstellen Sie zuerst ein Datenbank-Backup, und stellen Sie sicher, dass Sie es zur\u00fcckspielen k\u00f6nnen. Dieser Schritt macht jeden anderen Fehler hier umkehrbar. Wie Sie ein Backup erstellen und pr\u00fcfen, zeigt WordPress-Datenbank sichern und den SQL-Export pr\u00fcfen<\/a>.<\/p>\n
      Arbeiten Sie dann Schl\u00fcssel f\u00fcr Schl\u00fcssel. F\u00fchren Sie Ihr SELECT<\/code> aus und lesen Sie die Zahl. Danach Ihr DELETE<\/code> mit genau demselben WHERE<\/code>:<\/p>\n
      SELECT COUNT(*) FROM wp_postmeta WHERE meta_key = 'alter_plugin_key';\n\nDELETE FROM wp_postmeta WHERE meta_key = 'alter_plugin_key' LIMIT 5000;<\/code><\/pre>\n
      Wiederholen Sie das DELETE<\/code>, bis es 0 betroffene Zeilen meldet. Das LIMIT<\/code> h\u00e4lt jede Anweisung kurz, damit das Zeitlimit Ihres Hosters sie nicht mitten im Lauf abbricht. Bricht ein langer Lauf trotzdem ab, hilft Datenbankbereinigung h\u00e4ngt oder endet mit einem Timeout<\/a>.<\/p>\n
      F\u00fcr den Embed-Cache nehmen Sie ein Muster statt einer Liste:<\/p>\n
      DELETE FROM wp_postmeta WHERE meta_key LIKE '\\_oembed\\_%' LIMIT 5000;<\/code><\/pre>\n
      Sie brauchen die Backslashes. In LIKE<\/code> steht ein Unterstrich ohne Backslash f\u00fcr ein beliebiges Zeichen, und '_oembed_%'<\/code> trifft dann auch Schl\u00fcssel, die Sie nicht gemeint haben.<\/p>\n
      Warum die Tabelle auf der Festplatte nicht schrumpft<\/h2>\n
      Nach einem gro\u00dfen L\u00f6schvorgang bleibt die Datengr\u00f6\u00dfe oft gleich. InnoDB beh\u00e4lt die frei gewordenen Seiten zur Wiederverwendung, statt sie an Ihr Dateisystem zur\u00fcckzugeben. Die erste Abfrage oben zeigt sie Ihnen als frei_mb<\/code>.<\/p>\n
      OPTIMIZE TABLE wp_postmeta;<\/code> baut die Tabelle neu auf und gibt den Platz zur\u00fcck, wenn Ihr Server jede Tabelle in einer eigenen Datei speichert. Bei aktuellem MySQL und MariaDB ist das die Voreinstellung. Bei einer gro\u00dfen Tabelle dauert der Neuaufbau und kann Schreibzugriffe sperren. W\u00e4hlen Sie daf\u00fcr eine ruhige Stunde. Mehr dazu unter WordPress-Datenbanktabellen sicher optimieren<\/a>.<\/p>\n
      Sie m\u00fcssen nicht nach jeder Bereinigung optimieren. Freier Platz in der Tabelle wird von Ihren n\u00e4chsten Eintr\u00e4gen wieder genutzt. Wichtig wird er erst, wenn Sie den Speicher zur\u00fcckbrauchen, etwa weil ein Backup am vollen Speicher scheitert<\/a>.<\/p>\n
      \u00dcberpr\u00fcfung<\/h2>\n
      Ihre Bereinigung ist fertig, wenn sich die Zahlen bewegt haben und Ihre Website nicht.<\/p>\n
      \n\n\n\n\n\n\n\n\n
      Pr\u00fcfung<\/th>\nErwartet<\/th>\n<\/tr>\n<\/thead>\n
      Schl\u00fcssel-Abfrage erneut ausf\u00fchren<\/td>\nDie gel\u00f6schten Schl\u00fcssel fehlen. Alle anderen haben dieselbe Zeilenzahl wie vorher.<\/td>\n<\/tr>\n
      Verwaisten-Z\u00e4hlung erneut ausf\u00fchren<\/td>\n0, wenn Sie verwaiste Zeilen bereinigt haben.<\/td>\n<\/tr>\n
      Drei Seiten \u00f6ffnen: eine mit dem Page-Builder gebaute, eine mit Bildern, ein Produkt, falls Sie einen Shop betreiben<\/td>\nAlle drei sehen aus wie vorher.<\/td>\n<\/tr>\n
      Einen Schl\u00fcssel eines lebenden Beitrags, den Sie nicht bereinigt haben, vorher und nachher z\u00e4hlen<\/td>\nDarf sich nicht \u00e4ndern.<\/strong> Ist die Zahl gesunken, war Ihr WHERE<\/code> weiter gefasst als gedacht. Spielen Sie das Backup zur\u00fcck.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
      Auf die letzte Zeile kommt es an. Eine Bereinigung, die die richtigen Zeilen entfernt, beweist f\u00fcr sich nichts. Sie muss die falschen Zeilen auch stehen lassen, und das zeigt Ihnen nur der Vorher-nachher-Vergleich eines Schl\u00fcssels, den Sie nicht angefasst haben.<\/p>\n
      Auf der Testseite hielt die vierte Zeile beide Male. Nach einem Lauf der Datenbankbereinigung blieb der nicht betroffene Schl\u00fcssel bei 7 Zeilen, und ein K\u00f6der-Schl\u00fcssel, den ein Muster ohne Backslashes tr\u00e4fe, blieb bei 1. Nach dem manuellen DELETE<\/code> oben, genau so eingegeben, verschwanden 3 Zeilen, der nicht betroffene Schl\u00fcssel blieb bei 14 und der K\u00f6der bei 2. Ohne Backslashes traf dasselbe Muster 5 Zeilen, die K\u00f6der eingeschlossen.<\/p>\n
      \n
      Wie AIOWS unterst\u00fctzt:<\/p>\n
      AIOWS Database Cleaner<\/h2>\n
      Database Cleaner, in der deutschen Oberfl\u00e4che \u201eDatenbankbereinigung\u201c, nimmt Ihnen den Routineteil dieses Artikels ab, damit Ihre Aufmerksamkeit bei dem Teil bleibt, der sie braucht.<\/p>\n
      Er \u00fcbernimmt die L\u00f6schungen ohne Ermessensfrage.<\/strong> Zwei seiner elf Aufgaben sind die sicheren aus diesem Artikel. Verwaiste Beitragsmetadaten entfernt die Zeilen in wp_postmeta<\/code>, deren Beitrag nicht mehr existiert, und sonst nichts. oEmbed-Cache entfernt die _oembed_<\/code>-Schl\u00fcssel mit maskiertem Unterstrich, die LIKE<\/code>-Falle von oben kann Sie also nicht treffen. Beitragsrevisionen l\u00f6scht \u00fcber WordPress selbst, das die Metadaten jeder Revision mitnimmt, und kann die neuesten Revisionen jedes Beitrags behalten.<\/p>\n
      Er zeigt Ihnen zuerst die Zahl.<\/strong> Jede Aufgabe zeigt, wie viele Zeilen sie entfernen w\u00fcrde, gez\u00e4hlt mit denselben Bedingungen wie das L\u00f6schen. Eine Aufgabe ohne Treffer k\u00f6nnen Sie nicht ausw\u00e4hlen. Bevor die verwaisten Metadaten gehen, listet die Best\u00e4tigung die Schl\u00fcssel mit den meisten verwaisten Zeilen und die Beitrags-IDs, auf die sie zeigten. Das ist Ihr letzter Blick darauf, was die Waisen einmal waren.<\/p>\n
      Er sichert zuerst, jedes Mal.<\/strong> Jede Bereinigung beginnt mit einem Backup der betroffenen Tabellen. L\u00e4sst es sich nicht schreiben, wird nichts gel\u00f6scht.<\/p>\n
      Optimieren bleibt getrennt.<\/strong> Tabellen optimieren ist eine eigene Schaltfl\u00e4che. Sie bereinigen, vergleichen Ihre Zahlen und geben den Platz zur\u00fcck, wann Sie wollen.<\/p>\n
      \"Die
      Jede Aufgabe zeigt ihre Anzahl, bevor Sie sie ausw\u00e4hlen.<\/figcaption><\/figure>\n
      Die Best\u00e4tigung f\u00fcr verwaiste Beitragsmetadaten lautete w\u00f6rtlich:<\/p>\n
      Dieser Vorgang erstellt zuerst ein Datenbank-Backup und l\u00f6scht dann die ausgew\u00e4hlten Elemente dauerhaft. Sind Sie sicher?\n\nVerwaiste Beitragsmetadaten, die gel\u00f6scht werden, nach Schl\u00fcssel:\norphan_test_0 \u00d717\norphan_test_1 \u00d717\norphan_test_2 \u00d716\nBeitrags-IDs 100.007\u2013100.011, 5 Objekte<\/code><\/pre>\n
      Seine Grenzen, offen gesagt. Er entscheidet nicht, welche Meta-Schl\u00fcssel Ihrer lebenden Beitr\u00e4ge Altlasten sind. Schl\u00fcssel entfernter Plugins, doppelte Zeilen und verwaiste Term- oder Benutzer-Metadaten geh\u00f6ren nicht zu seinen Aufgaben. Die bleiben bei Ihnen, Schl\u00fcssel f\u00fcr Schl\u00fcssel, wie im Abschnitt \u00fcber Altlasten beschrieben. Medien im Papierkorb l\u00f6scht er nicht, weil ein Datenbank-Backup die Dateien nicht zur\u00fcckbringt. Den Papierkorb der Mediathek leeren Sie selbst. Und er sagt Ihnen nicht, warum Ihre Tabelle gewachsen ist. Das zeigt Ihnen die Schl\u00fcssel-Abfrage am Anfang, und die lohnt sich vor jedem Werkzeug.<\/p>\n
      AIOWS Database Cleaner ansehen<\/a>AIOWS-Pl\u00e4ne vergleichen<\/a><\/p>\n<\/section>\n
      H\u00e4ufige Fragen<\/h2>\n
      Ist eine wp_postmeta-Tabelle mit 500 MB ein Problem?<\/strong> Nicht f\u00fcr sich genommen. Wichtig wird es, wenn Ihre Abfragen auf diese Tabelle langsam werden oder Ihre Backups und Ihr Speicher leiden. Die Schl\u00fcsselliste zeigt Ihnen, ob die Gr\u00f6\u00dfe Inhalt ist, den Sie brauchen, oder Daten, die weg k\u00f6nnen.<\/p>\n
      Kann ich alle Schl\u00fcssel mit Unterstrich l\u00f6schen?<\/strong> Nein. Der Unterstrich blendet einen Schl\u00fcssel nur in Ihrer Box f\u00fcr benutzerdefinierte Felder aus. Ihre Bilder, Layouts und Shopdaten liegen alle in solchen Schl\u00fcsseln.<\/p>\n
      Macht das L\u00f6schen verwaister Metadaten etwas kaputt?<\/strong> Nein, wenn Ihre Abfrage wie oben mit wp_posts<\/code> verkn\u00fcpft. Eine verwaiste Zeile geh\u00f6rt zu keinem Beitrag, Ihre Website kann sie also nirgends anzeigen.<\/p>\n
      Warum ist die Tabelle nach der Bereinigung gleich gro\u00df?<\/strong> InnoDB beh\u00e4lt den frei gewordenen Platz in der Datei. OPTIMIZE TABLE<\/code> gibt ihn zur\u00fcck. Siehe Warum die Tabelle nicht schrumpft<\/a>.<\/p>\n
      Macht eine gro\u00dfe wp_postmeta-Tabelle meine Website langsam?<\/strong> Sie kann Ihre Abfragen verlangsamen, die nach Meta-Werten filtern, etwa manche Shop- und Suchabfragen. Seiten aus Ihrem Cache betrifft das nicht. Messen Sie, bevor Sie es annehmen.<\/p>\n
      Quellen<\/h2>\n