MySQL> La tabella non esiste. Ma lo fa (o dovrebbe)

Ho cambiato il datadir di un'installazione di MySQL e tutte le basi si sono spostate correttamente tranne una. Posso connettermi e USEil database. SHOW TABLESinoltre restituisce correttamente tutte le tabelle e i file di ciascuna tabella esistono nella directory dei dati MySQL.

Tuttavia, quando provo a SELECTqualcosa dalla tabella, ricevo un messaggio di errore che la tabella non esiste. Tuttavia, questo non ha senso poiché sono stato in grado di mostrare la stessa tabella attraverso l' SHOW TABLESaffermazione.

La mia ipotesi è che SHOW TABLESelenca l'esistenza dei file ma non controlla se un file è danneggiato o meno. Di conseguenza, posso elencare quei file ma non accedervi.

Tuttavia, è solo una supposizione. Non l'ho mai visto prima. Ora, non riesco a riavviare il database per il test, ma ogni altra applicazione che lo utilizza funziona correttamente. Ma è solo una supposizione, non l'ho mai visto prima.

Qualcuno sa perché questo sta accadendo?

Esempio:

mysql> SHOW TABLES;
+-----------------------+
| Tables_in_database    |
+-----------------------+
| TABLE_ONE             |
| TABLE_TWO             |
| TABLE_THREE           |
+-----------------------+
mysql> SELECT * FROM TABLE_ONE;
ERROR 1146 (42S02): Table 'database.TABLE_ONE' doesn't exist

Nel caso in cui qualcuno si preoccupi ancora:

Ho avuto lo stesso problema dopo aver copiato una directory del database usando direttamente il comando

cp -r /path/to/my/database /var/lib/mysql/new_database

Se lo fai con un database che utilizza le InnoDBtabelle, otterrai questo folle errore "tabella non esiste" menzionato sopra.

Il problema è che sono necessari i ib*file nella radice del datadir di MySQL (ad es ibdata1. ib_logfile0E ib_logfile1).

Quando ho copiato quelli ha funzionato per me.

Per me su Mac OS (installazione MySQL DMG) un semplice riavvio del server MySQL ha risolto il problema. Immagino che l'ibernazione lo abbia causato.

Ottengo questo problema quando il caso per il nome della tabella che sto usando è disattivato. Quindi la tabella si chiama 'db' ma ho usato 'DB' nell'istruzione select. Assicurarsi che il caso sia lo stesso.

Questo errore può verificarsi anche quando si imposta lower_case_table_namessu 1e quindi si tenta di accedere alle tabelle create con il valore predefinito per quella variabile. In tal caso puoi ripristinarlo al valore precedente e sarai in grado di leggere la tabella.

1. basta mysqld
2. cartella mysql di backup: cp -a /var/lib/mysql /var/lib/mysql-backup
3. copia la cartella del database dalla vecchia macchina a /var/lib/mysql
4. sovrascrive ib * (ib_logfile *, ibdata) dal vecchio database
5. avvia mysqld
6. dump dabase
7. mysqldump >dbase.mysql
8. interrompere il servizio mysql
9. rimuovere /var/lib/mysql
10. rinominare /var/lib/mysql-backupin/var/lib/mysql
11. avvia mysqld
12. creare il database
13. mysqldump < dbase.mysql

Si prega di eseguire la query:

SELECT 
    i.TABLE_NAME AS table_name, 
    LENGTH(i.TABLE_NAME) AS table_name_length,
    IF(i.TABLE_NAME RLIKE '^[A-Za-z0-9_]+$','YES','NO') AS table_name_is_ascii
FROM
    information_schema.`TABLES` i
WHERE
    i.TABLE_SCHEMA = 'database'

Purtroppo MySQL consente l'utilizzo di caratteri unicode e non stampabili nel nome della tabella. Se hai creato le tue tabelle copiando il codice di creazione da un documento / sito Web, è possibile che abbia spazio a larghezza zero da qualche parte.

Ho appena trascorso tre giorni in questo incubo. Idealmente, dovresti avere un backup che puoi ripristinare, quindi rilasciare semplicemente la tabella danneggiata. Questo tipo di errori può far crescere enormemente ibdata1 (100 GB + di dimensione per tabelle modeste)

Se non si dispone di un backup recente, ad esempio se si fa affidamento su mySqlDump, è probabile che i backup si siano interrotti in modo silenzioso a un certo punto in passato. Dovrai esportare i database, cosa che ovviamente non puoi fare, perché otterrai errori di blocco durante l'esecuzione di mySqlDump.

Quindi, come soluzione alternativa, vai a /var/log/mysql/database_name/e rimuovi table_name. *

Quindi prova immediatamente a scaricare la tabella; farlo ora dovrebbe funzionare. Ora ripristina il database su un nuovo database e ricostruisci le tabelle mancanti. Quindi scaricare il database danneggiato.

Nel nostro caso ricevevamo costantemente mysql has gone awaymessaggi a intervalli casuali su tutti i database; una volta rimosso il database danneggiato, tutto è tornato alla normalità.

Non conosco il motivo, ma nel mio caso ho risolto solo disabilitando e abilitando il controllo delle chiavi esterne

SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;

Ho avuto lo stesso problema e ho cercato per 2-3 giorni, ma la soluzione per me è stata davvero stupida.

Riavvia il mysql

$ sudo service mysql restart

Ora le tabelle diventano accessibili.

Ok, sembrerà abbastanza assurdo, ma umorizzami.
Per me il problema è stato risolto quando ho cambiato la mia dichiarazione in questo:

SELECT * FROM `table`

Ho apportato due modifiche
1.) Ho reso il nome della tabella in minuscolo - lo so !!
2.) Utilizzato il simbolo di citazione specifico = ` : è la chiave sopra il TAB

La soluzione sembra assurda, ma ha funzionato ed è sabato sera e lavoro dalle 9 di mattina - Quindi lo prenderò :)

In bocca al lupo.

Ho avuto questo problema dopo l'aggiornamento di WAMP ma senza backup del database.

Questo ha funzionato per me:

1. Ferma la nuova WAMP

2. Copia su directory di database necessarie e file ibdata1 dalla vecchia installazione di WAMP

3. Elimina ib_logfile0eib_logfile1

4. Avvia WAMP

Ora dovresti essere in grado di eseguire backup dei tuoi database. Tuttavia, dopo il riavvio del server, si verificano ancora problemi. Quindi ora reinstalla WAMP e importa i tuoi database.

Prova a eseguire la query sql per eliminare il tablespace prima di copiare il file idb:

ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

Copia il file idb

ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

Riavvia MySql

Dopo aver reinstallato MySQL ho avuto lo stesso problema, sembra che durante l'installazione, alcuni file di configurazione che memorizzano i dati sui file di registro di InnoDB, questi file ib_logfile * (sono file di registro giusti?), Vengano sovrascritti. Per risolvere questo problema ho appena eliminato i file ib_logfile *.

Ciò che ha funzionato per me è stato semplicemente lasciar cadere il tavolo, anche se non esisteva. Quindi ho creato la tabella e ripopolato da un dump sql fatto in precedenza.

Ci deve essere una metabase di nomi di tabelle, ed era probabilmente ancora esistente fino a quando non l'ho lasciato cadere.

Ha avuto un problema simile con un tavolo fantasma. Per fortuna aveva un dump SQL da prima dell'errore.

Nel mio caso, ho dovuto:

1. Ferma mySQL
2. Sposta i file ib * da /var/mysql off a un backup
3. Elimina /var/mysql/{dbname}
4. Riavvia mySQL
5. Ricrea database vuoto
6. Ripristina file di dump

NOTA: richiede il file di dump.

1. Esegui mysqldump nel database:

   mysqldump -u user -ppass dbname > D:\Back-ups\dbname.sql

2. Ripristina database

   mysql -u user -ppass dbname < D:\Back-ups\dbname.sql

Ora tutte le tabelle nel database sono state ripristinate completamente. Provare..

SELECT * FROM dbname.tablename;

Ho installato MariaDB su un nuovo computer, ho interrotto il servizio Mysql rinominato la cartella dei dati in dati. Ho risolto il mio problema copiando solo Mysql \ data \ table_folders e ibdata1 dalla cartella di dati MySql HD in crash alla nuova cartella di dati mysql installata.

Ho ignorato ib_logfile0 e ib_logfile1 (altrimenti il ​​server non ha avviato il servizio)

Servizio mysql avviato.

Quindi il server è in esecuzione.

Sembra che il problema abbia a che fare (almeno nel mio e in alcuni altri) con file di registro innodb non validi (corrotti?). In generale, devono semplicemente essere ricreati.

Ecco le soluzioni, molte delle quali richiedono un riavvio di mysql.

• Ricrea i tuoi file di registro ( Elimina e riavvia mysql )
• Ridimensiona i tuoi file di registro (MySql 5.6+ rigenererà il file per te)
• Se stai eseguendo un tipo di migrazione dei dati, assicurati di aver migrato correttamente il file corretto e di avergli concesso le autorizzazioni come altri hanno già dichiarato
• Controlla le autorizzazioni dei tuoi dati e file di registro, che mysql sia il proprietario di entrambi
• Se tutto il resto fallisce, probabilmente dovrai ricreare il database

Ecco un altro scenario (aggiornamento della versione) :

Ho reinstallato il mio sistema operativo (Mac OS El Captain) e installato una nuova versione di mysql (usando homebrew). La versione installata (5.7) è risultata essere più recente della mia precedente. Quindi ho copiato le tabelle, inclusi i file ib *, e riavviato il server. Ho potuto vedere le tabelle in mysql workbench ma quando ho provato a selezionare qualcosa, ho ottenuto "La tabella non esiste".

Soluzione:

1. arrestare il server mysql, ad esempio mysql.server stopobrew services stop mysql
2. avviare il server utilizzando mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/(modificare il percorso in base alle esigenze)
3. esegui mysql_upgrade -u root -p password(in un'altra finestra del terminale)
4. chiudere il server in esecuzione mysqladmin -u root -p password shutdown
5. riavviare il server in modalità normale mysql.server startobrew services start mysql

I documenti pertinenti sono qui .

Nel mio caso, avevo definito un trigger sulla tabella e quindi cercavo di inserire la riga nella tabella. sembra, in qualche modo il trigger era errato, e quindi inserire stava dando errore, la tabella non esiste.

È possibile che tu abbia un personaggio nascosto nel nome della tabella. Quelli non vengono visualizzati quando si eseguono tabelle di uno spettacolo. Riesci a fare una "SHOW CREATE TABLE TABLE_ONE" e la scheda completa il "TABLE_ONE" e vedi se inserisce caratteri nascosti. Inoltre, hai provato a far cadere e rifare i tavoli. Solo per assicurarsi che nulla sia sbagliato con i privilegi e che non ci siano personaggi nascosti.

Stesso problema esatto dopo l'importazione del backup di TimeMachine. La mia soluzione era quella di arrestare il server MySQL e correggere i permessi di lettura / scrittura sui file ib *.

Un'altra risposta che ritengo valga la pena riportare qui (perché sono venuto qui con lo stesso problema e questa si è rivelata la risposta per me):

Controlla attentamente che il nome della tabella nella tua query sia scritto esattamente lo stesso come nel database.

Un po ' ovvio, cosa da principiante, ma cose come "utente" vs "utenti" possono far inciampare le persone e ho pensato che sarebbe stata una risposta utile avere nell'elenco qui. :)

Nel mio caso, quando stavo importando il file sql esportato, ottenevo un errore come la tabella non esiste per la query di creazione della tabella.

Mi sono reso conto che c'era un carattere di sottolineatura nel nome del mio database e mysql stava mettendo un carattere di escape poco prima.

Quindi ho rimosso quel carattere di sottolineatura nel nome del database, tutto ha funzionato.

Spero che aiuti anche qualcun altro.

Il mio tavolo era stato in qualche modo ribattezzato ' Customers'con uno spazio iniziale

Questo significava

a) domande interrotte

b) il tavolo non è apparso come previsto nell'ordine alfabetico dei miei tavoli, il che nel mio panico significava che non riuscivo a vederlo!

RENAME TABLE ` Customer` TO `Customer`;

Nel mio caso era un SQLCA.DBParmparametro.

ero solito

SQLCA.DBParm = "Databse = "sle_database.text""

ma deve essere

SQLCA.DBParm = "Database='" +sle_database.text+ "'"

Spiegazione:

Combinerai tre stringhe:

 1. Database='              -  "Database='"

 2. (name of the database)  - +sle_database.text+

 3. '                       - "'" (means " ' "  without space)

Non usare spazi nei quatermarks. Grazie al mio collega Jan.

Vai a: xampp\mysql\data\dbname
all'interno di dbname sono presenti tablename.frm e file tablename.ibd.
rimuovilo e riavvia mysql e riprova.

Copia solo il ibdata1file dalla tua vecchia directory dei dati. Non copiare ib_logfile1o ib_logfile0file. Ciò farà sì che MySQL non si avvii più.

Oggi ho attraversato lo stesso problema. Questo è un problema mysql "Identifier Case Sensitivity".

Si prega di controllare il file di dati corrispondente. È molto probabile che il nome del file sia in minuscolo sul file system ma il nome della tabella elencato nel comando "mostra tabelle" sia in maiuscolo. Se la variabile di sistema " lower_case_table_names" è 0, la query restituirà "tabella non esistente" perché i confronti dei nomi fanno distinzione tra maiuscole e minuscole quando " lower_case_table_names" è 0.

Ho avuto lo stesso problema in Windows. Oltre a copiare i file ib * e la directory mysql nella directory dei dati thd, ho dovuto anche abbinare il file my.ini.

Il file my.ini della mia installazione precedente non aveva la seguente riga:

innodb-page-size=65536

Ma la mia nuova installazione ha fatto. Forse perché non avevo quell'opzione nel programma di installazione precedente. Ho rimosso questo e riavviato il servizio e le tabelle hanno funzionato come previsto. In breve, assicurati che il nuovo file my.ini sia una replica di quello vecchio, con la sola eccezione del datadir, del plugin-dir e del numero di porta, a seconda della tua nuova installazione.