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

Eu mudei o datadir de uma instalação do MySQL e seguindo alguns passos, funcionou bem. Cada base que eu tinha era movida corretamente, mas uma.

Eu posso conectar e usar o database, mesmo SHOW TABLES me retorna todas as tabelas corretamente e os arquivos de cada tabela existe no diretório de dados mysql. Mas quando eu tento SELECIONAR algo lá, diz que a tabela não existe. Mas a tabela existe, mostra até mesmo na instrução SHOW TABLES!

Meu palpite é que o SHOW TABLES lista a existência de arquivos de alguma forma que os arquivos estão corrompidos ou algo assim, mas não verifica isso. Então eu posso listá-los, mas não acessá-los.

Mas isso é apenas um palpite, eu nunca vi isso antes. Não é possível reiniciar o database agora para teste, todos os outros aplicativos que o utilizam estão funcionando bem.

Alguém sabe o que é isso?

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 importa:

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

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

Se você fizer isso com um database que usa tabelas InnoDB , você receberá este erro ‘tabela não existe’ mencionado acima.

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

Quando copiei, funcionou para mim.

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

Eu recebo este problema quando o caso para o nome da tabela que estou usando está desativado. Então, a tabela é chamada de ‘db’, mas eu usei ‘DB’ no comando select. Certifique-se de que o caso seja o mesmo.

Esse erro também pode ocorrer ao configurar lower_case_table_names como 1 e, em seguida, tentar acessar tabelas que foram criadas com o valor padrão para essa variável. Nesse caso, você pode reverter para o valor anterior e poderá ler a tabela.

  1. pare o mysqld
  2. pasta de backup mysql: cp -a /var/lib/mysql /var/lib/mysql-backup
  3. Copie a pasta do database da máquina antiga para /var/lib/mysql
  4. substitua ib * (ib_logfile *, ibdata) do database antigo
  5. iniciar o mysqld
  6. despejar dabase
  7. mysqldump >dbase.mysql
  8. pare o serviço mysql
  9. remove /var/lib/mysql
  10. renomear /var/lib/mysql-backup para /var/lib/mysql
  11. iniciar o mysqld
  12. criar o database
  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, há uma chance de que ele tenha espaço de largura zero em algum lugar.

Acabei de passar três dias neste pesadelo. Idealmente, você deve ter um backup que possa ser restaurado e simplesmente soltar a tabela danificada. Esses tipos de erros podem fazer com que seu ibdata1 cresça (100GB + em tamanho para tabelas modestas)

Se você não tiver um backup recente, como se você dependesse do mySqlDump, provavelmente os backups dele falharam em algum momento no passado. Você precisará exportar os bancos de dados, o que obviamente você não pode fazer, porque você obterá erros de bloqueio durante a execução do mySqlDump.

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

Então imediatamente tente despejar a mesa; fazer isso agora deve funcionar. Agora restaure o database para um novo database e reconstrua a (s) tabela (s) ausente (s). Em seguida, despeje o database quebrado.

No nosso caso, também estávamos constantemente recebendo mensagens mysql has gone away em intervalos randoms em todos os bancos de dados; uma vez que o database danificado foi removido, tudo voltou ao normal.

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

 ALTER TABLE mydatabase.mytable DISCARD TABLESPACE; 

Copie o arquivo idb

 ALTER TABLE mydatabase.mytable IMPORT TABLESPACE; 

Reinicie o MySql

Ok, isso vai soar muito absurdo, mas me agrade.
Para mim, o problema foi resolvido quando mudei minha declaração para isso:

 SELECT * FROM `table` 

Fiz duas alterações
1.) Feito o nome da tabela minúscula – eu sei !!
2.) Usou o símbolo da citação específica = ` : É a chave acima da sua TAB

A solução parece absurda, mas funcionou e é sábado à noite e eu tenho trabalhado desde 9:00 – Então eu vou levá-lo 🙂

Boa sorte.

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.

Depois de ter que reinstalar o MySQL eu tive esse 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 sobrescritos. Para resolver esse problema, acabei de excluir os arquivos ib_logfile *.

Tive 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 * do /var/mysql para um backup
  3. Excluir /var/mysql/{dbname}
  4. Reinicie o mySQL
  5. Recriar database vazio
  6. Restaurar arquivo de despejo

NOTA: Requer arquivo de despejo.

Eu tive esse problema depois de atualizar o WAMP, mas não tendo nenhum backup de database.

Isso funcionou para mim:

  1. Pare de novo WAMP

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

  3. Exclua ib_logfile0 e ib_logfile1

  4. Iniciar WAMP

Agora você deve ser capaz de fazer backups de seus bancos de dados. No entanto, após o servidor reiniciar novamente, você ainda terá problemas. Então agora reinstale o WAMP e importe seus bancos de dados.

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

Deve haver alguma metabase de nomes de tabela, e provavelmente ainda existia lá até que eu a deixei cair.

Instalei o MariaDB no novo computador, parei o serviço Mysql renomeado pasta de dados para dados – resolvi meu problema copiando apenas Mysql \ data \ table_folders e ibdata1 da pasta de dados HD MySql para a nova pasta de dados mysql instalada.

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

Serviço de mysql iniciado.

Então o servidor está sendo executado.

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

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

  • Recriar seus arquivos de log ( Excluir e reiniciar o mysql )
  • Redimensione seus arquivos de log (o MySql 5.6 + irá gerar o arquivo para você)
  • Se você estiver fazendo algum tipo de migration de dados, verifique se migrou corretamente o arquivo correto e concedeu as permissions, conforme já foi informado por outros usuários.
  • Verifique as permissions dos seus dados e arquivos de log, que o mysql é proprietário de ambos
  • Se tudo mais falhar, você provavelmente terá que recriar o database

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

Eu reinstalei meu sistema operacional (Mac OS El Captain) e instalei uma nova versão do mysql (usando 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 pude ver as tabelas no mysql workbench, mas quando tentei selecionar qualquer coisa, eu tenho “Tabela não existe”.

Solução:

  1. parar o servidor mysql eg mysql.server stop ou brew services stop mysql
  2. inicie o servidor usando mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/ (altere o caminho conforme necessário)
  3. execute 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 start ou brew services start mysql

Documentos relevantes estão aqui .

Eu não sei o motivo mas no meu caso eu resolvi apenas desabilitar e habilitar o checagem de foreign keys

 SET FOREIGN_KEY_CHECKS=0; SET FOREIGN_KEY_CHECKS=1; 

É possível que você tenha um caractere oculto no nome da sua tabela. Aqueles não aparecem quando você faz um show de tabelas. Você pode fazer um “SHOW CREATE TABLE TABLE_ONE” e tab completa o “TABLE_ONE” e ver se ele coloca em algum caracter oculto. Além disso, você tentou descartar e refazer as tabelas. Apenas para garantir que nada esteja errado com os privilégios e que não haja caracteres ocultos.

Mesmo problema exato após a importação de backup do TimeMachine. Minha solução foi parar o servidor MySQL e corrigir as permissions de leitura e gravação nos arquivos ib *.

Uma outra resposta que eu acho que vale a pena mencionar aqui (porque eu vim com o mesmo problema e esta acabou sendo a resposta para mim):

Verifique se o nome da tabela em sua consulta está exatamente igual ao do database.

É uma novidade óbvia, mas coisas como “usuário” versus “usuários” podem enganar as pessoas e achei que seria uma resposta útil na lista aqui. 🙂

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

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

Então eu removi esse sublinhado no nome do database, tudo deu certo.

Espero que ajude alguém também.

No meu caso, foi o parâmetro SQLCA.DBParm .

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 em marcas de referência. Agradeço ao meu colega Jan.

Vá para: xampp\mysql\data\dbname
inside dbname tem o arquivo tablename.frm e o arquivo tablename.ibd.
remova-o e reinicie o mysql e tente novamente.

No meu caso, eu tinha definido um gatilho na mesa e, em seguida, estava tentando inserir a linha na tabela. Parece que, de alguma forma, o gatilho foi errôneo e, portanto, a inserção estava dando erro, a tabela não existe.

  1. Do mysqldump para o database:

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

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

Agora todas as tabelas no database foram restauradas completamente. Experimentar..

 SELECT * FROM dbname.tablename; 

Copie apenas o arquivo ibdata1 do seu diretório de dados antigo. Não copie os arquivos ib_logfile0 ou ib_logfile0 . Isso fará com que o MySQL não inicie mais.

Veio cruzar o mesmo problema hoje. Este é um problema de “Sensibilidade de caso de identificador” 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 letras maiúsculas. Se a variável de sistema ” lower_case_table_names ” for 0, a consulta retornará “table not exist” porque as comparações de nomes lower_case_table_names maiúsculas de minúsculas quando ” lower_case_table_names ” é 0.

Eu tive o mesmo problema, mas não foi devido a um personagem oculto ou “mesa do schroedinger”. O problema (exatamente como mencionado acima) apareceu após um processo de restauração. Estou usando o administrador do MySQL versão 1.2.16. Quando uma restauração tiver que ser executada, você deve ter o ORIGINAL desmarcado no esquema de destino e selecionar o nome da sua base de dados na checkbox de seleção. Depois disso, o problema foi corrigido. Pelo menos essa foi a razão no meu database.

Se houver um ponto no nome da tabela, ele falhará para SELECT * FROM poorly_named.table;

Use backticks para obter a tabela SELECT * FROM `poorly_named.table`;