MySQL> Tabela não existe. Mas faz (ou deveria)

Mudei o datadir de uma instalação do MySQL e todas as bases foram movidas corretamente, exceto uma. Eu posso conectar e USEo banco de dados. SHOW TABLEStambém me devolve todas as tabelas corretamente e os arquivos de cada tabela existem no diretório de dados do MySQL.

No entanto, quando tento SELECTalgo da tabela, recebo uma mensagem de erro informando que a tabela não existe. No entanto, isso não faz sentido, pois pude mostrar a mesma tabela por meio de uma SHOW TABLESdeclaração.

Meu palpite é que SHOW TABLESlista a existência do arquivo, mas não verifica se um arquivo está corrompido ou não. Conseqüentemente, posso listar esses arquivos, mas não acessá-los.

No entanto, é apenas um palpite. Eu nunca vi isso antes. Agora, não consigo reiniciar o banco de dados para teste, mas todos os outros aplicativos que o utilizam estão funcionando bem. Mas isso é apenas um palpite, nunca vi isso antes.

Alguém sabe por que isso está acontecendo?

Exemplo:

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

Apenas no caso de alguém ainda se importar:

Eu tive o mesmo problema depois de copiar um diretório de banco de dados diretamente usando o comando

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

Se você fizer isso com um banco de dados que usa InnoDBtabelas, receberá esse erro louco 'tabela não existe' mencionado acima.

O problema é que você precisa dos ib*arquivos na raiz do datadir do MySQL (por exemplo ibdata1, ib_logfile0e ib_logfile1).

Quando copiei aqueles, funcionou para mim.

Para mim, no Mac OS (Instalação do MySQL DMG), uma simples reinicialização do servidor MySQL resolveu o problema. Eu estou supondo que a hibernação causou isso.

Recebo esse problema quando o caso do nome da tabela que estou usando está desativado. Então, a tabela é chamada 'db', mas eu usei 'DB' na instrução select. Verifique se o caso é o mesmo.

Este erro também pode ocorrer quando a configuração lower_case_table_namespara 1, em seguida, tentando tabelas de acesso que foram criados com o valor padrão para essa variável. Nesse caso, você pode revertê-lo para o valor anterior e poderá ler a tabela.

1. pare o mysqld
2. pasta mysql de backup: cp -a /var/lib/mysql /var/lib/mysql-backup
3. copiar a pasta do banco de dados da máquina antiga para /var/lib/mysql
4. substituir ib * (ib_logfile *, ibdata) do banco de dados antigo
5. inicie o mysqld
6. despejar dabase
7. mysqldump >dbase.mysql
8. parar o serviço mysql
9. remover /var/lib/mysql
10. renomeie /var/lib/mysql-backuppara/var/lib/mysql
11. inicie o mysqld
12. crie o banco de dados
13. mysqldump < dbase.mysql

Por favor, execute a consulta:

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'

Infelizmente, o MySQL permite que caracteres unicode e não imprimíveis sejam usados ​​no nome da tabela. Se você criou suas tabelas copiando o código de criação de algum documento / site, é possível que ele tenha espaço de largura zero em algum lugar.

Acabei de passar três dias nesse pesadelo. Idealmente, você deve ter um backup que possa restaurar e simplesmente soltar a tabela danificada. Esses tipos de erros podem fazer com que o ibdata1 cresça imenso (100 GB ou mais em tabelas modestas)

Se você não possui um backup recente, como se dependesse do mySqlDump, provavelmente os backups foram interrompidos silenciosamente em algum momento do passado. Você precisará exportar os bancos de dados, o que obviamente não poderá, porque você receberá erros de bloqueio ao executar o mySqlDump.

Portanto, como solução alternativa, vá para /var/log/mysql/database_name/e remova o table_name. *

Em seguida, tente imediatamente despejar a mesa; fazer isso agora deve funcionar. Agora restaure o banco de dados em um novo banco de dados e reconstrua as tabelas ausentes. Em seguida, despeje o banco de dados quebrado.

No nosso caso, também recebíamos mysql has gone awaymensagens constantemente em intervalos aleatórios em todos os bancos de dados; Depois que o banco de dados danificado foi removido, tudo voltou ao normal.

Não sei o motivo, mas no meu caso resolvi apenas desabilitar e habilitar a verificação de chaves estrangeiras

SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;

Eu tive o mesmo problema e procurei por 2-3 dias, mas a solução para mim foi realmente estúpida.

Reinicie o mysql

$ sudo service mysql restart

Agora as tabelas se tornam acessíveis.

Ok, isso vai parecer um absurdo, mas me humor.
Para mim, o problema foi resolvido quando mudei minha declaração para isso:

SELECT * FROM `table`

Fiz duas alterações
1.) Fiz o nome da tabela em letras minúsculas - eu sei !!
2.) Utilizou o símbolo de cotação específico = ` : É a chave acima do seu TAB

A solução parece absurda, mas funcionou e é sábado à noite e eu trabalho desde as 9 da manhã - então eu aceito :)

Boa sorte.

Eu tive esse problema depois de atualizar o WAMP, mas sem backup do banco de dados.

Isso funcionou para mim:

1. Pare o novo WAMP

2. Copie os diretórios do banco de dados necessários e o arquivo ibdata1 da instalação antiga do WAMP

3. Excluir ib_logfile0eib_logfile1

4. Iniciar o WAMP

Agora você deve conseguir fazer backup dos seus bancos de dados. No entanto, depois que o servidor reiniciar novamente, você ainda terá problemas. Então agora reinstale o WAMP e importe seus bancos de dados.

Tente executar a consulta sql para descartar o espaço de tabela antes de copiar o arquivo idb:

ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

Copiar arquivo idb

ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

Reinicie o MySql

Depois de ter que reinstalar o MySQL, tive o mesmo problema, parece que durante a instalação, alguns arquivos de configuração que armazenam dados sobre os arquivos de log do InnoDB, esses arquivos ib_logfile * (são arquivos de log, certo?), São substituídos. Para resolver esse problema, acabei de excluir os arquivos ib_logfile *.

O que funcionou para mim foi apenas derrubar a mesa, mesmo que ela não existisse. Então eu criei a tabela e repovoei a partir de um dump sql feito anteriormente.

Deve haver alguma metabase dos nomes das tabelas, e provavelmente ainda existia lá até que eu a soltasse.

Teve um problema semelhante com uma mesa fantasma. Felizmente teve um despejo de SQL antes da falha.

No meu caso, eu tive que:

1. Pare o mySQL
2. Mover arquivos ib * de /var/mysql off para um backup
3. Excluir /var/mysql/{dbname}
4. Reinicie o mySQL
5. Recriar banco de dados vazio
6. Restaurar arquivo de despejo

NOTA: Requer arquivo de despejo.

1. Faça o mysqldump no banco de dados:

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

2. Restaurar banco de dados

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

Agora todas as tabelas no banco de dados foram restauradas completamente. Experimentar..

SELECT * FROM dbname.tablename;

Eu instalei o MariaDB em um novo computador, parei o serviço Mysql renomeado pasta de dados para dados - resolvi meu problema ao copiar apenas Mysql \ data \ table_folders e ibdata1 da pasta de dados MySql HD travada para a nova pasta de dados mysql instalada.

Ignorei ib_logfile0 e ib_logfile1 (caso contrário, o servidor não iniciou o serviço)

Iniciado o serviço mysql.

Então o servidor está em execução.

Parece que o problema tem a ver (pelo menos no meu e em alguns outros) com arquivos de log inválidos (corrompidos?) Do innodb. De um modo geral, eles simplesmente precisam ser recriados.

Aqui estão as soluções, a maioria das quais requer a reinicialização do mysql.

• Recrie seus arquivos de log ( exclua e reinicie o mysql )
• Redimensione seus arquivos de log (o MySql 5.6+ irá gerar novamente o arquivo para você)
• Se você estiver realizando algum tipo de migração de dados, verifique se migrou corretamente o arquivo certo e concedeu permissões, conforme já indicado por outras pessoas.
• Verifique as permissões dos seus dados e arquivos de log, para que o mysql seja o proprietário de ambos
• Se tudo mais falhar, você provavelmente precisará recriar o banco de dados

Aqui está outro cenário (atualização de versão) :

Reinstalei meu sistema operacional (Mac OS El Captain) e instalei uma nova versão do mysql (usando o homebrew). A versão instalada (5.7) era mais recente que a anterior. Depois copiei as tabelas, incluindo os arquivos ib *, e reiniciei o servidor. Eu podia ver as tabelas no banco de dados mysql, mas quando tentei selecionar qualquer coisa, obtive "Tabela não existe".

Solução:

1. pare o servidor mysql, por exemplo, mysql.server stopoubrew services stop mysql
2. inicie o servidor usando mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/(altere o caminho conforme necessário)
3. corre mysql_upgrade -u root -p password (em outra janela do terminal)
4. desligar o servidor em execução mysqladmin -u root -p password shutdown
5. reinicie o servidor no modo normal mysql.server startoubrew services start mysql

Os documentos relevantes estão aqui .

No meu caso, eu havia definido um gatilho na tabela e, em seguida, estava tentando inserir a linha na tabela. parece que, de alguma forma, o gatilho estava errado e, portanto, o insert estava dando erro, a tabela não existe.

É possível que você tenha um personagem oculto no nome da sua tabela. Aqueles não aparecem quando você faz um show tables. Você pode fazer um "SHOW CREATE TABLE TABLE_ONE" e completar a guia "TABLE_ONE" e ver se ele coloca caracteres ocultos. Além disso, você já tentou largar e refazer as tabelas. Apenas para garantir que não haja nada errado com os privilégios e que não haja caracteres ocultos.

O mesmo problema exato após a importação do backup do TimeMachine. Minha solução foi parar o servidor MySQL e corrigir permissões de leitura e gravação nos arquivos ib *.

Acho que vale a pena trazer uma outra resposta aqui (porque eu vim aqui com o mesmo problema e isso acabou sendo a resposta para mim):

Verifique se o nome da tabela na sua consulta está escrito exatamente o mesmo que no banco de dados.

Uma coisa óbvia para iniciantes, mas coisas como "usuário" vs "usuários" podem enganar as pessoas, e eu pensei que seria uma resposta útil ter na lista aqui. :)

No meu caso, quando eu estava importando o arquivo sql exportado, estava recebendo um erro como a tabela não existe para a consulta de criação de tabela.

Percebi que havia um sublinhado no nome do meu banco de dados e o mysql estava colocando um caractere de escape logo antes disso.

Então eu removi esse sublinhado no nome do banco de dados, tudo deu certo.

Espero que ajude outra pessoa também.

De alguma forma, minha mesa foi renomeada para, ' Customers'ou seja, com um espaço à esquerda

Isso significava

a) consultas quebradas

b) a tabela não apareceu onde era esperado na ordem alfabética das minhas tabelas, o que em meu pânico significou que eu não podia vê-la!

RENAME TABLE ` Customer` TO `Customer`;

No meu caso, foi SQLCA.DBParmparâmetro.

eu usei

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

mas deve ser

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

Explicação:

Você vai combinar três strings:

 1. Database='              -  "Database='"

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

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

Não use espaços nas marcas de referência. Agradeço ao meu colega Jan.

Vá para: xampp\mysql\data\dbname
dentro do dbname, os arquivos tablename.frm e tablename.ibd.
remova-o e reinicie o mysql e tente novamente.

Copie apenas o ibdata1arquivo do seu diretório de dados antigo. Não copie ib_logfile1ou ib_logfile0arquivos. Isso fará com que o MySQL não inicie mais.

Veio atravessar o mesmo problema hoje. Este é um problema "Identifier Case Sensitivity" do mysql.

Por favor, verifique o arquivo de dados correspondente. É muito provável que o nome do arquivo esteja em minúsculas no sistema de arquivos, mas o nome da tabela listado no comando "show tables" esteja em maiúsculas. Se a variável de sistema " lower_case_table_names" for 0, a consulta retornará "tabela inexistente" porque as comparações de nome diferenciam maiúsculas de minúsculas quando " lower_case_table_names" é 0.

Eu tive o mesmo problema no Windows. Além de copiar os arquivos ib * e o diretório mysql no diretório thd data, também tive que corresponder ao arquivo my.ini.

O arquivo my.ini da minha instalação anterior não tinha a seguinte linha:

innodb-page-size=65536

Mas minha nova instalação fez. Possivelmente porque eu não tinha essa opção no instalador mais antigo. Eu removi isso e reiniciei o serviço e as tabelas funcionaram conforme o esperado. Resumindo, verifique se o novo arquivo my.ini é uma réplica do antigo, com a única exceção sendo o datadir, o dir-do-plugin e o número da porta, dependendo da sua nova instalação.