Jak naprawić brakujący klucz główny w tabeli WordPress wp_options

W skrócie: Brakujący klucz główny w tabeli wp_options oznacza, że MySQL przestaje automatycznie inkrementować option_id, więc nowe wiersze są zapisywane z wartością option_id = 0. WordPress nadal działa, ale każdy eksport, migracja czy push ze środowiska Staging kończy się błędem zduplikowanego klucza, a zapytania do tabeli stają się wolniejsze, ponieważ MySQL nie może już korzystać z klucza. Najszybsza naprawa: wykonaj kopię zapasową bazy danych, ponumeruj na nowo zduplikowane wartości option_id, tak aby każda była unikalna, następnie uruchom ALTER TABLE wp_options ADD PRIMARY KEY (option_id) i przywróć AUTO_INCREMENT. Całą naprawę możesz przeprowadzić w phpMyAdmin lub za pomocą surowego SQL i nie potrzebujesz żadnego pluginu.

Czasami, w określonych okolicznościach, tabela wp_options (lub dowolna inna tabela) może stracić swój indeks klucza głównego. Dokładna przyczyna rzadko jest oczywista. W zgłoszeniach do wsparcia WP STAGING najczęściej widzimy to w bazach danych, które zostały ręcznie zmigrowane z jednego serwera na drugi lub przeniesione narzędziem, które nie uwzględniało każdego przypadku, na przykład przy zmianie wersji MySQL albo między silnikami magazynu InnoDB i MyISAM.

Dla jasności: WP STAGING nie jest przyczyną tego błędu. WP STAGING jedynie pomaga ci go wykryć, wyświetlając wyraźne ostrzeżenie w panelu administratora WordPress, gdy znajdzie tabelę systemową bez klucza głównego. Sygnalizujemy to wcześnie, ponieważ jest to problem krytyczny i podstępny. Twoja witryna nadal ładuje się tak, jakby wszystko było w porządku, więc nie zauważysz go, dopóki migracja lub kopia zapasowa nie zakończy się niepowodzeniem, a wtedy tabela może już zawierać setki uszkodzonych wierszy. Im dłużej problem pozostaje nienaprawiony, tym więcej zduplikowanych wierszy się gromadzi i tym więcej pracy wymaga naprawa.

Czym jest klucz główny i dlaczego wp_options go potrzebuje

Klucz główny to kolumna (lub zestaw kolumn), która jednoznacznie identyfikuje każdy wiersz w tabeli. W standardowej instalacji WordPress tabela wp_options używa option_id jako klucza głównego. option_id jest zdefiniowany jako bigint(20) unsigned NOT NULL auto_increment, co oznacza, że baza danych automatycznie przypisuje każdemu nowemu wierszowi kolejny nieużywany numer i gwarantuje, że żadne dwa wiersze nie mają tej samej wartości.

Gdy ten klucz znika, psują się dwie rzeczy:

• Automatyczna inkrementacja zatrzymuje się. Bez klucza głównego MySQL nie inkrementuje już option_id. Każdy nowy wiersz jest wstawiany z wartością domyślną 0. Poniższy oryginalny przykład pokazuje, jak wygląda prawidłowa sekwencja:A tak wygląda ta sama kolumna, gdy klucza już nie ma i gromadzą się nowe wiersze z option_id = 0:
• Eksporty i migracje kończą się niepowodzeniem. Kolumna klucza głównego musi zawierać unikalne wartości. W momencie, gdy wyeksportujesz te wiersze i zaimportujesz je do innej bazy danych, MySQL odrzuca duplikaty z błędem typu Cannot insert duplicate key, a import zatrzymuje się w połowie. To dlatego WP STAGING i każdy inny plugin migracyjny nie może ukończyć transferu bazy danych, gdy brakuje klucza. Push z witryny Staging na produkcję kończy się niepowodzeniem dokładnie w punkcie, w którym zapisywane są zduplikowane wiersze 0.

Jest też cichszy koszt. wp_options to jedna z najczęściej odczytywanych tabel w WordPress, ponieważ opcje ładowane automatycznie (autoload) są pobierane niemal przy każdym żądaniu. W naszych testach brakujący klucz główny zmusza MySQL do powrotu do pełnego skanowania tabeli przy wyszukiwaniach, które w innym przypadku korzystałyby z klucza, co dodaje mierzalne obciążenie zwykłym ładowaniom strony. Jeśli chcesz dowiedzieć się, jak wp_options wpisuje się w szerszy schemat, zobacz nasz przewodnik po najważniejszych tabelach bazy danych WordPress.

Jak potwierdzić, że klucz główny rzeczywiście jest brakujący

Zanim cokolwiek zmienisz, potwierdź, że to naprawdę twój problem. Otwórz narzędzie do obsługi bazy danych, takie jak phpMyAdmin lub Adminer, wybierz swoją bazę danych WordPress i uruchom:

SHOW CREATE TABLE wp_options;

W prawidłowej tabeli wynik zawiera wiersz w rodzaju PRIMARY KEY (option_id), a kolumna option_id jest oznaczona jako AUTO_INCREMENT. Jeśli brakuje obu, klucz zniknął. Możesz też wypisać indeksy bezpośrednio:

SHOW INDEX FROM wp_options;

Tabela z nienaruszonym kluczem zwraca wiersz, w którym Key_name to PRIMARY. Jeśli tego wiersza nie ma, klucza głównego nie ma.

Ten zrzut ekranu pokazuje zwykłą tabelę wp_options z kluczem głównym ustawionym na kolumnie option_id:

Drugi zrzut ekranu pokazuje tę samą tabelę z brakującym kluczem głównym:

Aby zobaczyć, ile wierszy jest już dotkniętych problemem, policz duplikaty:

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

Każda grupa z option_id = 0 i liczbą powyżej jeden potwierdza uszkodzone wiersze, które trzeba ponumerować na nowo, zanim klucz będzie można przywrócić.

Zastępuj wp_options swoją rzeczywistą nazwą tabeli w całym poradniku, jeśli twoja instalacja używa niestandardowego prefiksu tabel (na przykład wp_xyz_options).

Zanim zaczniesz: wykonaj kopię zapasową bazy danych

Każdy z poniższych kroków modyfikuje bazę danych bezpośrednio, więc najpierw wykonaj pełną kopię zapasową i pobierz ją z serwera. Jeśli coś pójdzie nie tak, będziesz potrzebować czystej kopii do przywrócenia. Kopia zapasowa WP STAGING, eksport z phpMyAdmin lub mysqldump są w porządku. To również dobry moment, aby wykonać pracę na kopii Staging zamiast na produkcji: sklonuj witrynę, napraw tabelę tam, potwierdź wynik i dopiero wtedy zastosuj tę samą naprawę w produkcyjnej bazie danych.

Napraw brakujący klucz główny w phpMyAdmin

Jeśli wolisz interfejs graficzny od surowego SQL, phpMyAdmin obsługuje całą naprawę z zakładki Structure.

1. Otwórz phpMyAdmin lub Adminer i przejdź do tabeli wp_options.
2. Najpierw zajmij się zduplikowanymi ID. Weź największą istniejącą wartość w kolumnie option_id i ponumeruj każdy wiersz z 0 po kolei, tak aby każda wartość znów była unikalna. Ten screencast pokazuje ponumerowanie:
3. Otwórz edytor indeksów tabeli:
4. Ustaw option_id jako klucz główny:
5. Jeśli zobaczysz błąd Duplicate entry '0' for key 'PRIMARY', część zduplikowanych ID nadal pozostaje w tabeli:
6. Znajdź pozostałe duplikaty i zwiększaj ich wartości, tak aby żadna się nie powtarzała, a następnie ponownie dodaj klucz główny. Gdy operacja się powiedzie, ponownie włącz automatyczną inkrementację na option_id, aby przyszłe wiersze numerowały się poprawnie.

Napraw brakujący klucz główny za pomocą SQL

Ta sama naprawa zajmuje trzy instrukcje, jeśli czujesz się komfortowo z konsolą SQL. Uruchom je w kolejności na swojej bazie danych WordPress.

Najpierw nadaj każdemu uszkodzonemu wierszowi z 0 świeży, unikalny numer, kontynuując od bieżącej wartości maksymalnej option_id:

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

Następnie dodaj klucz główny, teraz gdy każda wartość jest już unikalna:

ALTER TABLE wp_options ADD PRIMARY KEY (option_id);

Na koniec przywróć automatyczną inkrementację, aby WordPress znów automatycznie numerował nowe opcje:

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

Oficjalna składnia tych instrukcji jest udokumentowana w podręczniku MySQL w sekcji ALTER TABLE. Kanoniczną definicję kolumn wp_options znajdziesz w opisie bazy danych WordPress, który wymienia dokładne typy kolumn oczekiwane przez rdzeń WordPress.

Zweryfikuj naprawę

Potwierdź, że naprawa się utrzymała, zanim zaufasz tabeli:

SHOW CREATE TABLE wp_options;

Wynik powinien teraz zawierać PRIMARY KEY (option_id) i pokazywać AUTO_INCREMENT na kolumnie option_id. Jako ostatnie sprawdzenie wstaw i usuń tymczasową opcję lub po prostu zapisz jakieś ustawienie w WordPress i potwierdź, że nowy wiersz otrzymuje unikalne, inkrementowane option_id, a nie kolejne 0.

Z kluczem ponownie na miejscu możesz uruchomić migrację lub push ze środowiska Staging, który wcześniej zawodził. Mimo to wykonaj świeżą kopię zapasową przed pushem, aby mieć punkt odzyskiwania zawierający naprawioną tabelę.

Co zrobić, jeśli ALTER TABLE się nie powiedzie

Ścieżka bez problemów obejmuje większość instalacji, ale kilka środowisk wymaga dodatkowej obsługi. Przejdź przez nie po kolei:

• Duplicate entry '0' for key 'PRIMARY'. Nie każdy duplikat został ponumerowany na nowo. Uruchom ponownie zapytanie zliczające duplikaty z sekcji diagnostycznej, ponumeruj pozostałe wiersze, a następnie ponownie dodaj klucz. To zdecydowanie najczęstszy powód, dla którego krok ALTER TABLE odmawia działania.
• Przekroczenie limitu czasu blokady na dużej tabeli. ALTER TABLE przepisuje tabelę i utrzymuje blokadę podczas działania. Na dużej tabeli wp_options lub na obciążonym serwerze produkcyjnym instrukcja może przekroczyć limit czasu. Uruchom naprawę w czasie małego ruchu, na klonie Staging lub użyj narzędzia do zmiany schematu online, takiego jak pt-online-schema-change, jeśli twój host je udostępnia.
• MyISAM zamiast InnoDB. Kroki działają na obu silnikach, ale WordPress działa najlepiej na InnoDB. Jeśli SHOW CREATE TABLE wp_options zgłasza ENGINE=MyISAM, rozważ konwersję po umieszczeniu klucza za pomocą ALTER TABLE wp_options ENGINE=InnoDB. Najpierw wykonaj kopię zapasową, ponieważ konwersja również przepisuje tabelę.
• Hosting blokuje zmiany schematu. Niektóre hosty zarządzane ograniczają bezpośrednie instrukcje DDL lub uruchamiają bazę danych pod użytkownikiem bez uprawnień ALTER. Jeśli instrukcja zakończy się błędem uprawnień, poproś swojego hosta o uruchomienie tych trzech instrukcji za ciebie lub o tymczasowe nadanie uprawnienia.

Nieudany ALTER TABLE to prawie zawsze jeden z tych czterech przypadków. Czytelnik śledzący leżący u podstaw błąd SQL w logu serwera może go znaleźć również w danych debugowania WordPress. Nasz przewodnik o tym, jak wykryć problem w tabelach bazy danych WordPress, opisuje, jak włączyć to logowanie.

Dlaczego ma to znaczenie dla migracji i pushów

Brakujący klucz główny to jeden z cichszych powodów, dla których przenoszenie witryny się zacina. Jeśli push ze środowiska Staging na live przekroczy limit czasu lub zostanie przerwany w połowie transferu, tabela wp_options jest głównym podejrzanym, zwłaszcza gdy w grę wchodzą zserializowane wartości opcji i liczba wierszy jest duża. To samo dotyczy zmiany hostów: czytelnicy zmagający się z siteurl i pętlami przekierowań po przeniesieniu, opisanymi w naszym przewodniku po migracji siteurl w wp_options, to dokładnie ta grupa, która może też nieść uszkodzony klucz główny ze starego serwera. Naprawienie klucza w pierwszej kolejności usuwa całą klasę niepowodzeń migracji, zanim się zaczną.

Powiązane artykuły

• Struktura bazy danych WordPress
• Pushowanie zmian ze środowiska Staging na produkcję
• Jak zmigrować witrynę WordPress na nowy host
• Pomijaj zamówienia i produkty WooCommerce
• Jak sprawdzić numer wersji WordPressa swojej witryny