Fehlenden Primary Key in der WordPress-Tabelle wp_options reparieren

Kurzfassung: Ein fehlender Primary Key auf der Tabelle wp_options führt dazu, dass MySQL die Spalte option_id nicht mehr automatisch hochzählt, sodass neue Zeilen mit option_id = 0 geschrieben werden. WordPress läuft weiter, aber jeder Export, jede Migration oder jeder Staging-Push schlägt mit einem Duplicate-Key-Fehler fehl, und Abfragen gegen die Tabelle werden langsamer, weil MySQL den Schlüssel nicht mehr nutzen kann. Die schnellste Lösung: Datenbank sichern, die doppelten option_id-Werte neu durchnummerieren, sodass jeder eindeutig ist, danach ALTER TABLE wp_options ADD PRIMARY KEY (option_id) ausführen und AUTO_INCREMENT wiederherstellen. Du kannst die gesamte Reparatur in phpMyAdmin oder mit reinem SQL durchführen, ein Plugin ist nicht nötig.

Unter bestimmten Umständen kann die Tabelle wp_options (oder jede andere Tabelle) ihren Primary-Key-Index verlieren. Der genaue Auslöser ist selten offensichtlich. In WP STAGING Support-Tickets sehen wir das am häufigsten bei Datenbanken, die manuell von einem Server auf einen anderen migriert wurden, oder die mit einem Tool verschoben wurden, das nicht jeden Fall berücksichtigt hat, etwa ein Wechsel zwischen MySQL-Versionen oder zwischen den Storage-Engines InnoDB und MyISAM.

Um es klarzustellen: WP STAGING ist nicht die Ursache dieses Fehlers. WP STAGING hilft dir nur, ihn zu erkennen, indem eine deutliche Warnung in deinem WordPress-Admin-Dashboard angezeigt wird, sobald eine Core-Tabelle ohne Primary Key gefunden wird. Wir machen darauf frühzeitig aufmerksam, weil es sich um ein kritisches und heimtückisches Problem handelt. Deine Website lädt weiter, als wäre alles in Ordnung, sodass du es erst bemerkst, wenn eine Migration oder ein Backup fehlschlägt, und bis dahin enthält die Tabelle vielleicht schon Hunderte defekter Zeilen. Je länger es unbehoben bleibt, desto mehr doppelte Zeilen sammeln sich an und desto aufwendiger wird die Reparatur.

Was ein Primary Key ist und warum wp_options einen braucht

Ein Primary Key ist eine Spalte (oder eine Gruppe von Spalten), die jede Zeile in einer Tabelle eindeutig identifiziert. In einer Standard-WordPress-Installation verwendet die Tabelle wp_options option_id als Primary Key. option_id ist als bigint(20) unsigned NOT NULL auto_increment definiert, was bedeutet, dass die Datenbank jeder neuen Zeile automatisch die nächste freie Nummer zuweist und garantiert, dass keine zwei Zeilen denselben Wert teilen.

Zwei Dinge gehen kaputt, wenn dieser Schlüssel verschwindet:

• Auto-Increment stoppt. Ohne den Primary Key zählt MySQL option_id nicht mehr hoch. Jede neue Zeile wird mit dem Standardwert 0 eingefügt. Das ursprüngliche Beispiel unten zeigt, wie eine gesunde Reihenfolge aussieht:Und so sieht dieselbe Spalte aus, sobald der Schlüssel weg ist und sich neue Zeilen mit option_id = 0 anstauen:
• Exporte und Migrationen schlagen fehl. Eine Primary-Key-Spalte muss eindeutige Werte enthalten. Sobald du diese Zeilen exportierst und in eine andere Datenbank importierst, weist MySQL die Duplikate mit einem Fehler wie Cannot insert duplicate key zurück, und der Import bricht mittendrin ab. Deshalb können WP STAGING und jedes andere Migrations-Plugin einen Datenbanktransfer nicht abschließen, wenn der Schlüssel fehlt. Der Push von einer Staging-Seite zur Produktion scheitert genau an der Stelle, an der die doppelten 0-Zeilen geschrieben werden.

Es gibt zudem einen leiseren Preis. wp_options ist eine der am häufigsten gelesenen Tabellen in WordPress, weil autoloaded Optionen bei nahezu jeder Anfrage abgerufen werden. In unseren Tests zwingt ein fehlender Primary Key MySQL dazu, für Abfragen auf einen vollständigen Tabellenscan zurückzufallen, die andernfalls den Schlüssel nutzen würden, was den gewöhnlichen Seitenaufruf messbar verlangsamt. Wenn du Hintergründe dazu möchtest, wie sich wp_options in das größere Schema einfügt, lies unseren Leitfaden zu den wichtigsten WordPress-Datenbanktabellen.

So bestätigst du, dass der Primary Key wirklich fehlt

Bevor du etwas änderst, vergewissere dich, dass das wirklich dein Problem ist. Öffne ein Datenbank-Tool wie phpMyAdmin oder Adminer, wähle deine WordPress-Datenbank aus und führe aus:

SHOW CREATE TABLE wp_options;

In einer gesunden Tabelle enthält die Ausgabe eine Zeile wie PRIMARY KEY (option_id) und die Spalte option_id ist als AUTO_INCREMENT markiert. Fehlen beide, ist der Schlüssel verschwunden. Du kannst die Indizes auch direkt auflisten:

SHOW INDEX FROM wp_options;

Eine Tabelle mit intaktem Schlüssel liefert eine Zeile zurück, in der Key_name gleich PRIMARY ist. Fehlt diese Zeile, gibt es keinen Primary Key.

Dieser Screenshot zeigt eine reguläre wp_options-Tabelle mit einem Primary Key auf der Spalte option_id:

Dieser zweite Screenshot zeigt dieselbe Tabelle mit fehlendem Primary Key:

Um zu sehen, wie viele Zeilen bereits betroffen sind, zähle die Duplikate:

SELECT option_id, COUNT(*) AS copies
FROM wp_options
GROUP BY option_id
HAVING copies > 1;

Jede Gruppe mit option_id = 0 und einem Zähler über eins bestätigt die defekten Zeilen, die du neu durchnummerieren musst, bevor der Schlüssel wiederhergestellt werden kann.

Ersetze wp_options überall durch deinen tatsächlichen Tabellennamen, falls deine Installation ein eigenes Tabellenpräfix verwendet (zum Beispiel wp_xyz_options).

Bevor du beginnst: Sichere die Datenbank

Jeder Schritt unten verändert die Datenbank direkt, also erstelle zuerst ein vollständiges Backup und lade es vom Server herunter. Falls etwas schiefgeht, willst du eine saubere Kopie zum Wiederherstellen haben. Ein WP STAGING Backup, ein phpMyAdmin-Export oder ein mysqldump sind alle in Ordnung. Das ist auch ein guter Moment, die Arbeit an einer Staging-Kopie statt an der Produktion durchzuführen: Klone die Seite, repariere die Tabelle dort, prüfe das Ergebnis und wende erst dann dieselbe Lösung auf die Live-Datenbank an.

Den fehlenden Primary Key in phpMyAdmin reparieren

Wenn du eine grafische Oberfläche gegenüber reinem SQL bevorzugst, erledigt phpMyAdmin die gesamte Reparatur über den Reiter „Struktur".

1. Öffne phpMyAdmin oder Adminer und navigiere zur Tabelle wp_options.
2. Kümmere dich zuerst um die doppelten IDs. Nimm den größten vorhandenen Wert in der Spalte option_id und nummeriere jede 0-Zeile einzeln neu, sodass jeder Wert wieder eindeutig ist. Dieser Screencast zeigt das Neudurchnummerieren:
3. Öffne den Index-Editor der Tabelle:
4. Setze option_id als Primary Key:
5. Wenn du den Fehler Duplicate entry '0' for key 'PRIMARY' siehst, sind noch einige doppelte IDs in der Tabelle:
6. Finde die übrigen Duplikate und zähle ihre Werte hoch, sodass sich keiner wiederholt, und füge dann den Primary Key erneut hinzu. Sobald es gelingt, aktiviere Auto-Increment auf option_id wieder, damit künftige Zeilen sich korrekt durchnummerieren.

Den fehlenden Primary Key mit SQL reparieren

Dieselbe Reparatur erfordert drei Anweisungen, wenn dir die SQL-Konsole vertraut ist. Führe sie der Reihe nach gegen deine WordPress-Datenbank aus.

Gib zuerst jeder defekten 0-Zeile eine neue eindeutige Nummer, indem du beim aktuellen Maximum von option_id fortfährst:

SET @next := (SELECT MAX(option_id) FROM wp_options);
UPDATE wp_options
SET option_id = (@next := @next + 1)
WHERE option_id = 0;

Füge als Nächstes den Primary Key hinzu, jetzt da jeder Wert eindeutig ist:

ALTER TABLE wp_options ADD PRIMARY KEY (option_id);

Stelle schließlich Auto-Increment wieder her, damit WordPress neue Optionen wieder automatisch durchnummeriert:

ALTER TABLE wp_options MODIFY option_id BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;

Die offizielle Syntax für diese Anweisungen ist im MySQL-Handbuch unter ALTER TABLE dokumentiert. Für die kanonische Definition der wp_options-Spalten listet die WordPress-Datenbankbeschreibung die exakten Spaltentypen auf, die der WordPress-Core erwartet.

Die Reparatur überprüfen

Bestätige, dass die Reparatur hält, bevor du der Tabelle vertraust:

SHOW CREATE TABLE wp_options;

Die Ausgabe sollte jetzt PRIMARY KEY (option_id) enthalten und AUTO_INCREMENT auf der Spalte option_id zeigen. Als letzte Kontrolle fügst du eine Wegwerf-Option ein und löschst sie wieder, oder speicherst einfach eine Einstellung in WordPress, und prüfst, ob die neue Zeile eine eindeutige, hochgezählte option_id erhält statt einer weiteren 0.

Mit dem wiederhergestellten Schlüssel kannst du die Migration oder den Staging-Push ausführen, der zuvor fehlschlug. Erstelle dennoch vor dem Push ein frisches Backup, damit du einen Wiederherstellungspunkt hast, der die reparierte Tabelle enthält.

Was zu tun ist, wenn ALTER TABLE fehlschlägt

Der reibungslose Weg deckt die meisten Installationen ab, aber einige Umgebungen brauchen eine zusätzliche Behandlung. Arbeite diese der Reihe nach durch:

• Duplicate entry '0' for key 'PRIMARY'. Nicht jedes Duplikat wurde neu nummeriert. Führe die Duplikatzählung aus dem Diagnoseabschnitt erneut aus, nummeriere die verbleibenden Zeilen neu und füge dann den Schlüssel erneut hinzu. Das ist der mit Abstand häufigste Grund, warum der Schritt ALTER TABLE sich weigert auszuführen.
• Lock-Wait-Timeout bei einer großen Tabelle. ALTER TABLE schreibt die Tabelle neu und hält während der Ausführung eine Sperre. Bei einer großen wp_options-Tabelle oder auf einem stark ausgelasteten Produktionsserver kann die Anweisung in ein Timeout laufen. Führe die Reparatur bei geringem Traffic durch, auf einem Staging-Klon, oder verwende ein Online-Schema-Change-Tool wie pt-online-schema-change, falls dein Hoster es bereitstellt.
• MyISAM statt InnoDB. Die Schritte funktionieren auf beiden Engines, aber WordPress läuft am besten auf InnoDB. Wenn SHOW CREATE TABLE wp_options ENGINE=MyISAM meldet, ziehe nach dem Setzen des Schlüssels eine Umstellung mit ALTER TABLE wp_options ENGINE=InnoDB in Betracht. Erstelle zuerst ein Backup, denn die Umstellung schreibt die Tabelle ebenfalls neu.
• Hosting blockiert Schemaänderungen. Manche Managed-Hoster schränken direkte DDL-Anweisungen ein oder betreiben die Datenbank unter einem Benutzer ohne ALTER-Rechte. Wenn die Anweisung mit einem Rechtefehler scheitert, bitte deinen Hoster, die drei Anweisungen für dich auszuführen, oder das Recht vorübergehend zu gewähren.

Ein fehlgeschlagenes ALTER TABLE ist fast immer einer dieser vier Fälle. Wer den zugrunde liegenden SQL-Fehler im Server-Log verfolgt, findet ihn möglicherweise auch in der WordPress-Debug-Ausgabe; unser Leitfaden dazu, wie man ein Problem in den WordPress-Datenbanktabellen aufspürt, erklärt, wie du diese Protokollierung einschaltest.

Warum das für Migrationen und Pushes wichtig ist

Ein fehlender Primary Key ist einer der leiseren Gründe, warum ein Seitenumzug ins Stocken gerät. Wenn ein Push von Staging zu Live in ein Timeout läuft oder mitten im Transfer abbricht, ist die Tabelle wp_options ein Hauptverdächtiger, besonders wenn serialisierte Optionswerte im Spiel sind und die Zeilenzahl groß ist. Dasselbe gilt beim Hosterwechsel: Wer nach einem Umzug mit siteurl und Weiterleitungsschleifen kämpft, behandelt in unserem Leitfaden zur Migration von siteurl in wp_options, ist genau das Publikum, das womöglich auch einen defekten Primary Key vom alten Server mitschleppt. Den Schlüssel zuerst zu reparieren, beseitigt eine ganze Klasse von Migrationsfehlern, bevor sie überhaupt entstehen.

Verwandte Artikel

• Die WordPress-Datenbankstruktur
• Änderungen von Staging zur Produktion pushen
• Wie du deine WordPress-Website zu einem neuen Hoster migrierst
• WooCommerce-Bestellungen und Produkte überspringen
• Wie du die WordPress-Versionsnummer deiner Website herausfindest