Tabella Schrödingers MySQL: esiste, ma non lo è

Sto avendo l'errore più strano di tutti.

A volte, durante la creazione o la modifica di tabelle, ottengo l'errore "tabella già esistente". Tuttavia, DROP TABLE restituisce "# 1051 - tabella sconosciuta". Quindi ho un tavolo che non posso creare, non posso rilasciare.

Quando provo a rilasciare il database, mysqld si blocca. A volte aiuta a creare un altro db con un nome diverso, a volte no.

Uso un DB con ~ 50 tabelle, tutte InnoDB. Questo problema si verifica con tabelle diverse.

L'ho sperimentato su Windows, Fedora e Ubuntu, MySQL 5.1 e 5.5. Stesso comportamento, quando si utilizza PDO, PHPMyAdmin o riga di comando. Uso MySQL Workbench per gestire il mio schema: ho visto alcuni errori correlati (endline e cose del genere), ma nessuno di loro era rilevante per me.

No, non è una vista, è un tavolo. Tutti i nomi sono minuscoli.

Ho provato tutto quello che potevo su google: svuotare le tabelle, spostare i file .frm da db a db, leggere il registro di mysql, niente ha aiutato se non reinstallare l'intera dannata cosa.

"Mostra tabelle" non rivela nulla, "descrive" la tabella dice "la tabella non esiste", non esiste un file .frm, tuttavia "crea tabella" termina ancora con un errore (e così fa "crea tabella se non esiste") e l'eliminazione del database provoca l'arresto anomalo di mysql

Domande correlate, ma inutili:

• Mysql 1050 Errore "Tabella già esistente" quando in realtà non lo è

• La tabella MySQL non esiste errore, ma esiste

Modificare:

mysql> use askyou;
Database changed

mysql> show tables;
Empty set (0.00 sec)

mysql> create table users_has_friends (id int primary key);
ERROR 1050 (42S01): Table '`askyou`.`users_has_friends`' already exists

mysql> drop table users_has_friends;
ERROR 1051 (42S02): Unknown table 'users_has_friends'

E così, lo stesso: la tabella non esiste, ma non può essere creata;

mysql> drop database askyou;
ERROR 2013 (HY000): Lost connection to MySQL server during query

I nomi cambiano, questa non è l'unica tabella / database con cui ho avuto problemi

Ho visto questo problema quando il file di dati non è presente nella directory dei dati ma il file di definizione della tabella esiste o viceversa. Se stai usando innodb_file_per_table, controlla la directory dei dati per assicurarti di avere sia un .frmfile che un file .ibd per la tabella in questione. Se è MYISAM, dovrebbero esserci a .frm, .MYIe a.MYD file.

Di solito il problema può essere risolto eliminando manualmente il file orfano.

Sto cercando di indovinare qui, ma sembra che innodb abbia ancora una voce per le tue tabelle in un tablespace, probabilmente in ibdata. Se davvero non hai bisogno di nessuno dei dati o se disponi di backup, prova quanto segue:

1. Elimina tutti gli schemi (escluso mysql)
2. chiudere il database
3. Assicurati che tutte le cartelle nella directory dei dati siano state rimosse correttamente (di nuovo, escluso mysql)
4. eliminare ibdata e file di registro
5. riavviare il database. Dovrebbe ricreare il tablespace e i log da zero.

La soluzione risulta essere facile; almeno quello che ho capito, ha funzionato per me. Crea una tabella "zzz" su un'altra istanza MySQL, dove zzz è il nome della tabella del problema. (cioè, se la tabella si chiama schrödinger, sostituitela con zzz ovunque sia scritta). Non importa quale sia la definizione della tabella. È un manichino temporaneo; Copia il file zzz.frm nella directory del database sul server in cui dovrebbe essere la tabella, assicurandoti che la proprietà e le autorizzazioni del file siano ancora corrette sul file. Su MySQL, ora puoi fare "mostra tabelle;" e la tabella zzz sarà lì. mysql> drop table zzz; ... ora dovrebbe funzionare. Se necessario, cancella tutti i file zzz.MYD o ZZZ.MYI nella directory.

Dubito che questa sia una risposta diretta al caso della domanda qui, ma ecco come ho risolto questo esatto problema percepito sul mio sistema OS X Lion.

Creo / elimino spesso tabelle per alcuni lavori di analisi che ho pianificato. Ad un certo punto, ho iniziato a ricevere errori di tabella già esistenti a metà del mio script. Un riavvio del server in genere risolveva il problema, ma era una soluzione troppo fastidiosa.

Quindi ho notato nel file di registro degli errori locale questa particolare riga:

[Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive

Questo mi ha dato l'idea che forse se le mie tabelle contenessero lettere maiuscole, MySQL sarebbe stato indotto a pensare che fossero ancora lì anche dopo averle lasciate cadere. Questo si è rivelato essere il caso e il passaggio all'utilizzo solo di lettere minuscole per i nomi delle tabelle ha risolto il problema.

È probabilmente il risultato di un errore di configurazione nel mio caso, ma si spera che questo caso di errore aiuti qualcuno a perdere meno tempo cercando di trovare una soluzione.

Questa è una vecchia domanda, ma ho appena incontrato lo stesso problema e una risposta in uno dei problemi correlati collegati in alto era proprio ciò di cui avevo bisogno e molto meno drastica dell'eliminazione di file, tabelle, spegnimento del server ecc.

mysqladmin -uxxxxxx -pyyyyy flush-tables

Nel mio caso il problema è stato risolto cambiando la proprietà della directory dei dati mysql all'utente che ha eseguito l'applicazione. (Nel mio caso si trattava di un'applicazione Java che eseguiva il server web Jetty.)

Anche se mysql era in esecuzione e altre app potevano usarlo correttamente, questa app aveva un problema con quello. Dopo aver modificato la proprietà della directory dei dati e reimpostato la password dell'utente, tutto ha funzionato correttamente.

Se sarà disponibile con questo errore 1051 e vuoi solo eliminare il database e importarlo di nuovo, fai questi passaggi e tutto andrà bene ....

in ambiente Unix come root :

• rm -rf / var / lib / mysql / YOUR_DATABASE;
• FACOLTATIVO -> mysql_upgrade --force
• mysqlcheck -uUSER -PASS YOUR_DATABASE
• mysqladmin -uUSER -pPASS rilascia il TUO_DATABASE
• mysqladmin -uUSER -pPASS crea IL TUO_DATABASE
• mysql -uUSER -pPASS YOUR_DATABASE <IMPORT_FILE

Saluti, Christus

Ho avuto questo problema e speravo che l'eliminazione del file IBD sarebbe stato d'aiuto come pubblicato sopra, ma non ha fatto differenza. MySQL ha ricreato solo un nuovo file IBD. Nel mio caso, ci sono effettivamente tabelle simili in altri database nella stessa istanza MySQL. Poiché il file FRM mancava, ho copiato il file FRM dalla tabella simile in un altro database, riavviato MySQL e la tabella ha funzionato correttamente.

Mi sono imbattuto in questo errore dopo aver creato una tabella e averla eliminata, quindi volevo crearla di nuovo. Nel mio caso, avevo un file di dump autonomo, quindi ho eliminato il mio schema, lo ho ricreato e ho importato tabelle e dati utilizzando il file di dump.

Succede nel nostro sito (ma raramente) di solito quando si verifica un "evento" durante l'esecuzione di alcuni script che richiedono molte ricostruzioni. Gli eventi includono interruzioni di rete o problemi di alimentazione.
Quello che faccio per questo nelle rarissime occasioni in cui accade - utilizzo l'approccio pesante:

• Dovevo semplicemente sbarazzarmi e ricostruire il particolare tavolo. Di solito sono in una posizione che va bene poiché il tavolo è in fase di costruzione. (La tua situazione potrebbe essere diversa se devi recuperare i dati)
• In qualità di amministratore, accedi all'installazione di mysql (su Windows potrebbe essere "... file di programma / mysql / MySQL Server xx / data / <schemaname>
• Trova il file incriminato con il nome della tabella nella cartella <schemaname> ed eliminalo.
• Controlla i file temporanei orfani ed elimina anche loro. # ... frm file se si trovano lì.
• MySQL ti permetterà di CREARE di nuovo la tabella

Ho avuto questo problema su un paio di database diversi per un lungo periodo (anni). È stato un ostacolo perché i messaggi contraddittori. La prima volta ho fatto una variazione dell'eliminazione / ricostruzione / ridenominazione del database come descritto nelle altre risposte e sono riuscito a far funzionare le cose, ma in questo modo ci vuole decisamente più tempo. Fortunatamente per me è sempre capitato di fare riferimento alle tabelle che vengono ricostruite - DROP'd e CREATEd - tipicamente al mattino. Raramente ho riscontrato il problema, ma è arrivato a riconoscerlo come un caso speciale eccentrico. (Ribadisco: se hai bisogno di recuperare i dati guarda alle altre soluzioni.)

• non è una tabella che appartiene a un altro utente o in un altro database
• non è il problema delle maiuscole / minuscole, io uso tutte le minuscole, ma era un problema interessante!
• è stato ancora più frustrante vedere le risposte con variazioni di "sicuramente era <there / not-there / some-other-user-table-case> e non lo stai facendo bene" :)
• la tabella non è stata visualizzata in "mostra tavoli"
• il tavolo era (è sempre stato / era stato) un tavolo INNODB.
• cercando di DROP la tabella ha dato il messaggio di errore che la tabella non esiste.
• ma provando a CREARE la tabella ha dato il messaggio di errore che la tabella esiste già.
• utilizzando mysql 5.0 o 5.1
• REPAIR è inefficace per questo problema

Ho riscontrato questo problema con un tavolo in particolare. Leggendo le possibili soluzioni ho fatto alcuni passaggi come:

• Cerca file orfani: non esisteva nessuno;
• eseguire:: show full tables in database;non ha visto quello problematico;
• eseguire describe table;:: restituito table doesn't exist;
• eseguire SELECT * FROM information_schema.TABLES WHERE TABLE_NAME='table';:: restituito Empty set;
• Cerca manualmente tramite phpMyAdmin la query sopra: non esisteva;

E, dopo questi passaggi, controllo di nuovo con show tables;e ... vualá! il tavolo problematico era sparito. Potevo crearlo e rilasciarlo con lo stesso nome problematico senza problemi, e non dovevo nemmeno riavviare il server! Strano...