Què importa primer: WordPress va arribar a la base de dades, però una taula no es pot llegir normalment. Els passos de reparació difereixen per a MyISAM i InnoDB, i una reparació visible pot fallar si es manté la pressió del disc o del maquinari.
Què indica realment aquest símptoma
Això no és el mateix que credencials de base de dades invàlides. El nom de la taula, el motor, el servidor registre i l’estat del disc determinen si una reparació a nivell de taula és apropiada o una restauració és més segura.
Recull proves abans de canviar res
- Escriu la taula exacta i l’error SQL.
- Crea un bolcat de base de dades o instantània d’emmagatzematge abans dels intents de reparació.
- Comprova el dorsal de la taula, espai lliure en disc i error de base de dades registre.
- Determinar si altres taules o bases de dades mostren corrupció.
Causes més habituals
- Un apagat brut: Un xoc o reinici forçat va deixar una taula no transaccional inconsistent.
- Problema de disc o sistema de fitxers: El disc complet, els errors d’E/S o l’emmagatzematge fallit interromp les escriptures.
- Dany a l’índex MyISAM: Les taules de llegat sovint es poden comprovar i reparar a nivell de taula.
- Corrupció InnoDB: El dany de la taula transaccional pot requerir mode de recuperació o restauració, no REPAIR TABLE.
Seqüència segura de diagnòstic i reparació
- Estabilitza l’espai al disc i el servei de base de dades abans de modificar la taula.
- Usa la TAULA DE VERIFICACIÓ per confirmar l’abast i l’orientació específica del motor.
- Repara només els motors compatibles, o restaurar la taula afectada d’una còpia de seguretat verificada.
- Executa controls a nivell d’aplicació després de la recuperació perquè l’èxit estructural no prova la integritat de les dades.
Com distingir entre les causes probables
No tractis Un apagat brut i Problema de disc o sistema de fitxers com a causes equivalents. Un xoc o reinici forçat va deixar una taula no transaccional inconsistent. En canvi, el disc complet, els errors d’E/S o l’emmagatzematge fallit interromp les escriptures. Per distingir- les, usa aquestes dues comprovacions: Escriu la taula exacta i l’error SQL; i crea un bolcat de base de dades o instantània d’emmagatzematge abans dels intents de reparació. Amb aquestes dades podreu decidir si convé aplicar la primera acció controlada — Estabilitzar l’espai en disc i el servei de base de dades abans de modificar la taula — o si has de conservar l’estat actual i ampliar la recerca.
En un lloc de WordPress en producció, repeteix la petició que falla mentre comprova una pàgina que funciona correctament i l’àrea d’administració. Un error aïllat en una ruta requereix un rollback més acotat que un problema que afecta PHP, la base de dades o totes les peticions. Documenta la data i hora exactes, la URL o transacció afectada, l’últim estat correcte conegut i cada canvi realitzat durant el diagnòstic. Aquest registre permet distingir una reparació reproduïble d’una desaparició temporal del símptoma.
Què no has de fer
No activeu valors agressius de recuperació de força InnoDB i continueu amb les escriptures normals. El mode de recuperació és per extreure dades en condicions controlades.
Com verificar la reparació
- La taula afectada passa els controls estructurals.
- WordPress llegeix i escriu correctament la característica relacionada.
- Base de dades i sistema registres no mostren errors d’E/S o corrupció continus.
Que el símptoma visible desaparegui no és suficient. Tanca la incidència només quan l’acció original que fallava, el recorregut de negoci relacionat i els registres rellevants confirmin que el problema ha desaparegut.
CRITERI D’INCIDENT WP REPAIR
Seqüència d’intervenció segura
Això no és el mateix que credencials de base de dades invàlides. El nom de la taula, el motor, el servidor registre i l’estat del disc determinen si una reparació a nivell de taula és apropiada o una restauració és més segura.
- Escriu la taula exacta i l’error SQL.
- Crea un bolcat de base de dades o instantània d’emmagatzematge abans dels intents de reparació.
- Comprova el dorsal de la taula, espai lliure en disc i error de base de dades registre.
- Determinar si altres taules o bases de dades mostren corrupció.
Què ha de quedar verificat
- La taula afectada passa els controls estructurals.
- WordPress llegeix i escriu correctament la característica relacionada.
- Base de dades i sistema registres no mostren errors d'E/S o corrupció continus.
Fonts tècniques oficials
Aquesta guia explica el diagnòstic. Si la web està afectada ara mateix, la intervenció ha de preservar una via de recuperació i verificar el recorregut real del negoci.
Veure el servei de reparació urgent →SOBRE ESTE SÍNTOMA
Preguntes freqüents d'aquesta guia.
És una taula estrellada el mateix problema que les credencials equivocades de la base de dades?+
No. Una taula es va estavellar significa que WordPress va assolir la base de dades amb èxit, però una taula específica no es pot llegir normalment, el que és un problema diferent d’un error de credencials o connexió. La ruta de reparació depèn del nom de la taula, el motor d’emmagatzematge i l’estat del disc, no de l’autenticació.
El procés de reparació difereix entre les taules MyISAM i InnoDB?+
Sí. Les taules MyISAM sovint es poden comprovar i reparar directament en el nivell de la taula. La corrupció InnoDB és diferent: podeu requerir el mode de recuperació o una restauració de backup en comptes d’una simple ordre REPAIR TABLE, atès que el motor transaccional maneja els danys de manera diferent.
És segur deixar la configuració de recuperació de força InnoDB després d’extreure les dades?+
No. Els valors agressius de recuperació de la força InnoDB estan destinats a extreure dades en condicions controlades, no per a continuar les operacions normals d’escriptura. Deixar-los habilitats durant l’ús regular pot causar més problemes en comptes de resoldre el problema subjacent.
Si l’ordre de reparació reporta èxit, vol dir que les dades estan completament intactes?+
No necessàriament. L’èxit estructural d’una ordre de reparació no prova la integritat de les dades — executi comprovacions a nivell d’aplicació després per confirmar que la característica afectada realment llegeix i escriu correctament, atès que algunes files o registres encara podrien faltar o alterar-se.