La table MySQL de Schrödingers : existe, mais elle ne l'est pas.

Question

J'ai l'erreur la plus bizarre de toutes.

Parfois, lorsque je crée ou modifie des tableaux, je reçois l'erreur "table already exists". Cependant, DROP TABLE renvoie le message "#1051 - unknown table". J'ai donc une table que je ne peux ni créer ni supprimer.

Lorsque j'essaie d'abandonner la base de données, mysqld se plante. Parfois, il est utile de créer une autre base de données avec un nom différent, parfois non.

J'utilise une BD avec ~50 tables, toutes InnoDB. Ce problème se produit avec différentes tables.

J'ai rencontré ce problème sous Windows, Fedora et Ubuntu, avec MySQL 5.1 et 5.5. Même comportement, que l'on utilise PDO, PHPMyAdmin ou la ligne de commande. J'utilise MySQL Workbench pour gérer mon schéma. J'ai vu quelques erreurs connexes (lignes de fin et autres), mais aucune d'entre elles n'était pertinente pour moi.

Non, ce n'est pas une vue, c'est une table. Tous les noms sont en minuscules.

J'ai essayé tout ce que j'ai pu trouver sur Google - vider les tables, déplacer les fichiers .frm d'un BD à l'autre, lire le journal mysql, rien ne m'a aidé sauf réinstaller tout le système.

L'option " Show tables " ne révèle rien, l'option " describe " indique " table doesn't exist ", il n'y a pas de fichier .frm, mais l'option " create table " se termine toujours par une erreur (tout comme l'option " create table if not exists ") et l'abandon de la base de données fait planter mysql.

Des questions connexes, mais inutiles :

• Mysql 1050 Erreur "La table existe déjà" alors qu'elle n'existe pas.

• Erreur "MySQL Table does not exist", mais elle existe bel et bien.

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'

Et tel, tout de même : la table n'existe pas, mais ne peut pas être créée ;

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

Changement de nom, ce n'est pas la seule table / base de données avec laquelle j'ai rencontré des problèmes.

Answer 1

J'ai vu ce problème lorsque le fichier de données est absent du répertoire de données mais que le fichier de définition de table existe ou vice-versa. Si vous utilisez innodb_file_per_table, vérifiez le répertoire de données pour vous assurer que vous avez à la fois un fichier de données et un fichier de définition de table. .frm et le fichier .ibd pour la table en question. Si c'est MYISAM, il devrait y avoir un fichier .frm , .MYI et un .MYD fichier.

Le problème peut généralement être résolu en supprimant manuellement le fichier orphelin.

Answer 2

Je me lance dans une supposition hasardeuse ici, mais il semble que innodb a toujours une entrée pour vos tables dans un tablespace, probablement dans ibdata . Si vous realmente n'ont pas besoin cualquier des données, ou si vous avez des sauvegardes, essayez ce qui suit :

1. Supprimer tous les schémas (sauf mysql)
2. fermer la base de données
3. Assurez-vous que tous les dossiers de votre répertoire de données ont été correctement supprimés (à l'exception de mysql).
4. supprimer les ibdata et les fichiers journaux
5. redémarrez la base de données. Cela devrait recréer le tablespace et les journaux à partir de zéro.

Answer 3

La solution s'avère facile ; du moins, ce que j'ai fait a fonctionné pour moi. Créez une table "zzz" sur une autre instance MySQL, où zzz est le nom de la table problématique. (c'est-à-dire que si la table s'appelle schrodinger, remplacez ce nom par zzz partout où c'est écrit). La définition de la table n'a pas d'importance. C'est un leurre temporaire ; Copiez le fichier zzz.frm dans le répertoire de la base de données sur le serveur où la table doit se trouver, en s'assurant que la propriété du fichier et les permissions sont toujours correctes sur le fichier. Sur MySQL, vous pouvez maintenant faire "show tables ;", et la table zzz sera là. mysql> drop table zzz ; ...devrait maintenant fonctionner. Effacez tout fichier zzz.MYD ou ZZZ.MYI dans le répertoire si nécessaire.

Answer 4

Je doute que ce soit une réponse directe à la question posée ici, mais voici comment j'ai résolu le problème ce même problème perçu sur mon système OS X Lion.

Je crée et dépose fréquemment des tableaux pour certains travaux d'analyse que j'ai programmés. À un moment donné, j'ai commencé à obtenir des erreurs de table déjà existante à mi-chemin de mon script. Un redémarrage du serveur résolvait généralement le problème, mais c'était une solution trop ennuyeuse.

J'ai ensuite remarqué cette ligne particulière dans le fichier journal des erreurs locales :

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

Cela m'a donné l'idée que peut-être, si mes tables contenaient des lettres majuscules, MySQL serait trompé en pensant qu'elles sont toujours là même après que je les ai supprimées. Cela s'est avéré être le cas et le fait d'utiliser uniquement des lettres minuscules pour les noms de tables a fait disparaître le problème.

Dans mon cas, il s'agit probablement du résultat d'une mauvaise configuration, mais j'espère que ce cas d'erreur permettra à quelqu'un de perdre moins de temps à essayer de trouver une solution.

Answer 5

Dans mon cas, le problème a été résolu en changeant la propriété du répertoire de données mysql à l'utilisateur qui exécute l'application. (Dans mon cas, il s'agissait d'une application Java exécutant le serveur Web Jetty).

Même si mysql fonctionnait et que les autres applications pouvaient l'utiliser correctement, cette application avait un problème avec ça. Après avoir changé la propriété du répertoire de données et réinitialisé le mot de passe de l'utilisateur, tout a fonctionné correctement.