Tabela Schrödingers MySQL: existe, mas não

Estou cometendo o erro mais estranho de todos.

Às vezes, ao criar ou alterar tabelas, recebo o erro 'tabela já existe'. No entanto, DROP TABLE retorna '# 1051 - tabela desconhecida'. Então eu tenho uma mesa que não posso criar, não posso largar.

Quando tento eliminar o banco de dados, o mysqld falha. Às vezes ajuda criar outro banco de dados com um nome diferente, às vezes não.

Eu uso um banco de dados com cerca de 50 tabelas, todas InnoDB. Esse problema ocorre com tabelas diferentes.

Eu experimentei isso no Windows, Fedora e Ubuntu, MySQL 5.1 e 5.5. Mesmo comportamento, ao usar PDO, PHPMyAdmin ou linha de comando. Eu uso o MySQL Workbench para gerenciar meu esquema - eu vi alguns erros relacionados (linhas finais e outras coisas), porém nenhum deles foi relevante para mim.

Não, não é uma vista, é uma mesa. Todos os nomes estão em minúsculas.

Eu tentei tudo que pude no google - esvaziar tabelas, mover arquivos .frm de db para db, ler o log do mysql, nada ajudou a não ser reinstalar a porcaria inteira.

'Mostrar tabelas' não revela nada, 'descrever' a tabela diz 'a tabela não existe', não há nenhum arquivo .frm, mas 'criar tabela' ainda termina com um erro (e também 'criar tabela se não existir') e eliminando falhas de banco de dados mysql

Perguntas relacionadas, mas inúteis:

• Erro Mysql 1050 "Tabela já existe" quando, na verdade, não existe

• Tabela MySQL não existe erro, mas existe

Editar:

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 assim mesmo: a mesa não existe, mas não pode ser criada;

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

Mudança de nomes, esta não é a única tabela / banco de dados que eu tive problemas com

Já vi esse problema quando o arquivo de dados está faltando no diretório de dados, mas o arquivo de definição de tabela existe ou vice-versa. Se você estiver usando innodb_file_per_table, verifique o diretório de dados para ter certeza de que possui um .frmarquivo e um arquivo .ibd para a tabela em questão. Se for MYISAM, deve haver um .frm, .MYIe um .MYDarquivo.

O problema geralmente pode ser resolvido excluindo o arquivo órfão manualmente.

Estou tentando adivinhar aqui, mas parece que o innodb ainda tem uma entrada para suas tabelas em um espaço de tabela, provavelmente em ibdata. Se você realmente não precisa de nenhum dos dados ou se possui backups, tente o seguinte:

1. Exclua todos os esquemas (excluindo mysql)
2. desligue o banco de dados
3. Certifique-se de que todas as pastas em seu diretório de dados foram removidas corretamente (novamente, excluindo mysql)
4. deletar ibdata e arquivos de log
5. reinicie o banco de dados. Ele deve recriar o espaço de tabela e os logs do zero.

A correção acabou sendo fácil; pelo menos o que eu fiz funcionou para mim. Crie uma tabela "zzz" em outra instância do MySQL, onde zzz é o nome da tabela do problema. (ou seja, se a mesa for chamada de schrodinger, substitua zzz onde estiver escrita.) Não importa qual seja a definição da mesa. É um manequim temporário; Copie o arquivo zzz.frm para o diretório do banco de dados no servidor onde a tabela deve estar, certificando-se de que a propriedade e as permissões do arquivo ainda estejam corretas. No MySQL, agora você pode fazer "show tables;" e a tabela zzz estará lá. mysql> drop table zzz; ... agora deve funcionar. Limpe todos os arquivos zzz.MYD ou ZZZ.MYI do diretório, se necessário.

Duvido que esta seja uma resposta direta ao caso de perguntas aqui, mas aqui está como resolvi exatamente esse problema percebido no meu sistema OS X Lion.

Eu freqüentemente crio / elimino tabelas para alguns trabalhos de análise que agendei. Em algum ponto, comecei a obter erros de tabela já existe no meio do meu script. A reinicialização do servidor normalmente resolvia o problema, mas essa era uma solução muito irritante.

Então, percebi no arquivo de registro de erros local esta linha específica:

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

Isso me deu a idéia de que talvez se minhas tabelas contivessem letras maiúsculas, o MySQL seria enganado e pensaria que ainda estavam lá mesmo depois de eu tê-las removido. Esse acabou sendo o caso, e mudar para o uso de apenas letras minúsculas nos nomes das tabelas fez o problema desaparecer.

Provavelmente é o resultado de alguma configuração incorreta no meu caso, mas espero que esse caso de erro ajude alguém a perder menos tempo tentando encontrar uma solução.

Esta é uma pergunta antiga, mas acabei de chegar ao mesmo problema e uma resposta em um dos problemas relacionados vinculados no topo era exatamente o que eu precisava e muito menos drástico do que excluir arquivos, tabelas, desligar o servidor etc.

mysqladmin -uxxxxxx -pyyyyy flush-tables

No meu caso, o problema foi resolvido alterando a propriedade do diretório de dados mysql para o usuário que executou o aplicativo. (No meu caso, era um aplicativo Java executando o servidor da web Jetty.)

Embora o mysql estivesse em execução e outros aplicativos pudessem usá-lo adequadamente, este aplicativo teve um problema com isso. Depois de alterar a propriedade do diretório de dados e redefinir a senha do usuário, tudo funcionou corretamente.

Se for estoque com este erro 1051 e você só quer deletar o banco de dados e importar novamente, siga estes passos e tudo vai dar certo ....

na raiz AS do ambiente Unix :

• rm -rf / var / lib / mysql / YOUR_DATABASE;
• OPCIONAL -> mysql_upgrade --force
• mysqlcheck -uUSER -pPASS YOUR_DATABASE
• mysqladmin -uUSER -pPASS drop YOUR_DATABASE
• mysqladmin -uUSER -pPASS criar YOUR_DATABASE
• mysql -uUSER -pPASS YOUR_DATABASE <IMPORT_FILE

Atenciosamente, Christus

Eu tive esse problema e esperava que excluir o arquivo IBD ajudasse conforme postado acima, mas não fez diferença. O MySQL recriou apenas um novo arquivo IBD. No meu caso, existem tabelas semelhantes em outros bancos de dados na mesma instância do MySQL. Como o arquivo FRM estava faltando, copiei o arquivo FRM da tabela semelhante em outro banco de dados, reiniciei o MySQL e a tabela funcionou corretamente.

Encontrei este erro depois de criar uma tabela e excluí-la, e depois quis criá-la novamente. No meu caso, eu tinha um arquivo de despejo autocontido, então eliminei meu esquema, o recriei e importei tabelas e dados usando o arquivo de despejo.

Isso acontece em nosso site (mas raramente) geralmente quando um "evento" acontece durante a execução de certos scripts que fazem muitas reconstruções. Os eventos incluem interrupções na rede ou problemas de energia.
O que eu faço para isso nas raras ocasiões em que acontece - eu uso a abordagem pesada:

• Eu precisava simplesmente livrar-me-e-reconstruir a tabela específica. Normalmente estou em uma posição de que isso está OK, pois a mesa está sendo construída. (Sua situação pode ser diferente se você precisar recuperar dados)
• Como administrador, vá para a instalação do mysql (no Windows pode ser "... arquivos de programa / mysql / Servidor MySQL xx / data / <schemaname>
• Encontre o arquivo incorreto com o nome da tabela na pasta <schemaname> - e exclua-o.
• Verifique se há arquivos temporários órfãos e exclua-os também. # ... arquivos frm se eles estiverem lá.
• O MySQL permitirá que você CRIE a tabela novamente

Eu tive esse problema em alguns bancos de dados diferentes por um longo tempo (anos). Foi um stumper por causa das mensagens contraditórias. Na primeira vez, fiz uma variação da exclusão / reconstrução / renomeação do banco de dados conforme descrito nas outras respostas e consegui fazer as coisas andarem, mas definitivamente leva mais tempo assim. Para minha sorte, sempre aconteceu a referência a tabelas que estão sendo reconstruídas - DROP'd e CREATEd - geralmente pela manhã. Raramente teve o problema, mas o reconheceu como um caso peculiar especial. (Vou reafirmar: se você precisa recuperar os dados, procure as outras soluções.)

• não é uma tabela pertencente a outro usuário, ou em outro banco de dados
• não é o problema de maiúsculas / minúsculas, eu uso todas as minúsculas, mas esse foi um problema interessante!
• foi ainda mais frustrante ver respostas com variações de "definitivamente estava <lá / não-lá / algum-outro-caso-tabela-usuário-caso> e você simplesmente não está fazendo certo" :)
• a tabela não apareceu em "mostrar tabelas"
• a mesa era (sempre foi / foi) uma mesa INNODB.
• tentar DROP a tabela gerou a mensagem de erro de que a tabela não existe.
• mas tentando CRIAR a tabela deu a mensagem de erro que a tabela já existe.
• usando mysql 5.0 ou 5.1
• REPAIR é ineficaz para este problema

Eu estava tendo esse problema com uma mesa específica. Lendo as soluções possíveis, fiz alguns passos como:

• Pesquisar arquivos órfãos: não existia ninguém;
• execute:: show full tables in database;não vi o problemático;
• execute describe table;:: retornado table doesn't exist;
• execute SELECT * FROM information_schema.TABLES WHERE TABLE_NAME='table';:: retornado Empty set;
• Pesquise pelo phpMyAdmin manualmente a consulta acima: não existia;

E, após esses passos, verifico novamente com o show tables;e ... vualá! a mesa problemática havia sumido. Eu poderia criá-lo e eliminá-lo com o mesmo nome problemático sem nenhum problema, e não precisei nem reiniciar o servidor! Esquisito...