Table MySQL de Schrödingers: existe, mais elle n'existe pas

J'ai la plus étrange erreur de toutes.

Parfois, lors de la création ou de la modification de tables, j'obtiens l'erreur «la table existe déjà». Cependant, DROP TABLE renvoie '# 1051 - table inconnue'. J'ai donc une table que je ne peux pas créer, je ne peux pas supprimer.

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

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

J'ai vécu cela sur Windows, Fedora et Ubuntu, MySQL 5.1 et 5.5. Même comportement, lors de l'utilisation de PDO, PHPMyAdmin ou de la ligne de commande. J'utilise MySQL Workbench pour gérer mon schéma - j'ai vu des erreurs liées (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 je pouvais sur google - vidanger les tables, déplacer les fichiers .frm de la base de la base vers la base de données, lire le journal mysql, rien n'a aidé à réinstaller le tout.

«Afficher les tables» ne révèle rien, «décrire» la table dit «la table n'existe pas», «il n'y a pas de fichier .frm, mais« créer une table »se termine toujours par une erreur (de même que« créer une table si elle n'existe pas ») et la suppression de la base de données plante mysql

Questions connexes, mais inutiles:

• Erreur Mysql 1050 "La table existe déjà" alors qu'en fait, elle ne l'est pas

• La table MySQL n'existe pas d'erreur, mais elle existe

Éditer:

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

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

J'ai vu ce problème lorsque le fichier de données est manquant dans le 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 disposez à la fois d'un .frmfichier et d' un fichier .ibd pour la table en question. Si c'est MyISAM, il devrait y avoir un .frm, .MYIet un .MYDfichier.

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

Faire une supposition sauvage ici, mais il semble que innodb ait toujours une entrée pour vos tables dans un tablespace, probablement dans ibdata. Si vous n'avez vraiment besoin d' aucune des données ou si vous avez des sauvegardes, essayez ce qui suit:

1. Supprimer tous les schémas (sauf mysql)
2. arrêter la base de données
3. Assurez-vous que tous les dossiers de votre répertoire de données ont été supprimés correctement (encore une fois, à l'exclusion de mysql)
4. supprimer les ibdata et les fichiers journaux
5. redémarrez la base de données. Il doit recréer le tablespace et les journaux à partir de zéro.

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

Je doute que ce soit une réponse directe au cas de question ici, mais voici comment j'ai résolu ce problème perçu exactement sur mon système OS X Lion.

Je crée / supprime fréquemment des tables pour certains travaux d'analyse que j'ai programmés. À un moment donné, j'ai commencé à avoir des erreurs de table qui existaient déjà à mi-chemin de mon script. Un redémarrage du serveur a généralement résolu le problème, mais c'était une solution trop ennuyeuse.

Ensuite, j'ai remarqué dans le fichier journal des erreurs local cette ligne particulière:

[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 si mes tables contenaient des lettres majuscules, MySQL serait dupe en pensant qu'elles sont toujours là même après les avoir supprimées. Cela s'est avéré être le cas et le fait de n'utiliser que des lettres minuscules pour les noms de table a résolu le problème.

C'est probablement le résultat d'une mauvaise configuration dans mon cas, mais j'espère que ce cas d'erreur aidera quelqu'un à perdre moins de temps à essayer de trouver une solution.

C'est une vieille question, mais je viens de frapper le même problème et une réponse à l'un des problèmes connexes liés en haut était exactement ce dont j'avais besoin et beaucoup moins drastique que la suppression de fichiers, de tables, l'arrêt du serveur, etc.

mysqladmin -uxxxxxx -pyyyyy flush-tables

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écutait l'application. (Dans mon cas, c'était une application Java exécutant le serveur Web Jetty.)

Même si mysql était en cours d'exécution et que d'autres applications pouvaient l'utiliser correctement, cette application avait un problème avec cela. 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.

Si vous êtes en stock avec cette erreur 1051 et que vous souhaitez uniquement supprimer la base de données et l'importer à nouveau, procédez comme suit et tout ira très bien ....

dans l'environnement Unix AS root :

• rm -rf / var / lib / mysql / VOTRE_DATABASE;
• FACULTATIF -> mysql_upgrade --force
• mysqlcheck -uUSER -pPASSER VOTRE_DATABASE
• mysqladmin -uUSER -pPASS drop YOUR_DATABASE
• mysqladmin -uUSER -pPASS créer VOTRE_DATABASE
• mysql -uUSER -pPASSER VOTRE_DATABASE <IMPORT_FILE

Cordialement, Christus

J'ai eu ce problème et j'espérais que la suppression du fichier IBD aiderait comme indiqué ci-dessus, mais cela ne faisait aucune différence. MySQL n'a recréé qu'un nouveau fichier IBD. Dans mon cas, il existe en fait des tables similaires dans d'autres bases de données dans la même instance MySQL. Comme le fichier FRM était manquant, j'ai copié le fichier FRM de la table similaire dans une autre base de données, redémarré MySQL et la table a fonctionné correctement.

J'ai rencontré cette erreur après avoir créé une table et l'ai supprimée, puis j'ai voulu la créer à nouveau. Dans mon cas, j'avais un fichier de vidage autonome, j'ai donc supprimé mon schéma, recréé et importé des tables et des données à l'aide du fichier de vidage.

Cela se produit sur notre site (mais rarement) généralement lorsqu'un "événement" se produit lors de l'exécution de certains scripts qui font beaucoup de reconstruction. Les événements incluent des pannes de réseau ou des problèmes d'alimentation.
Ce que je fais pour cela dans les très rares occasions où cela se produit - j'utilise l'approche brutale:

• J'avais besoin de simplement me débarrasser et reconstruire la table particulière. Je suis généralement dans une position que c'est OK puisque la table est en cours de construction. (Votre situation peut être différente si vous avez besoin de récupérer des données)
• En tant qu'administrateur, accédez à l'installation de mysql (sous Windows, il peut s'agir de "... program files / mysql / MySQL Server xx / data / <schemaname>
• Recherchez le fichier incriminé avec le nom de la table dans le dossier <schemaname> et supprimez-le.
• Recherchez les fichiers temporaires orphelins et supprimez-les également. # ... fichiers frm s'ils s'y trouvent.
• MySQL vous permettra de CRÉER à nouveau la table

J'ai eu ce problème sur quelques bases de données différentes pendant une longue période (années). C'était un stumper parce que les messages contradictoires. La première fois, j'ai fait une variante de la base de données de suppression / reconstruction / changement de nom comme décrit dans les autres réponses et j'ai réussi à faire avancer les choses, mais cela prend certainement plus de temps de cette façon. Heureusement pour moi, il est toujours arrivé à des tables de référence qui sont reconstruites - DROP'd et CREATEd - généralement le matin. Rarement eu le problème mais en est venu à le reconnaître comme un cas spécial et original. (Je vais répéter: si vous avez besoin de récupérer les données, regardez les autres solutions.)

• ce n'est pas une table appartenant à un autre utilisateur, ou dans une autre base de données
• ce n'est pas le problème des majuscules / minuscules, j'utilise toutes les minuscules, mais c'était un problème intéressant!
• c'était encore plus frustrant de voir les réponses avec des variantes de "c'était définitivement <there / not-there / some-other-user-table-case> et vous ne faites tout simplement pas les choses correctement" :)
• le tableau n'apparaissait pas sur "afficher les tableaux"
• la table était (était / avait toujours été) une table INNODB.
• essayer de DROP la table a donné le message d'erreur que la table n'existe pas.
• mais essayer de CRÉER la table a donné le message d'erreur que la table existe déjà.
• en utilisant mysql 5.0 ou 5.1
• REPAIR est inefficace pour ce problème

J'avais ce problème avec une table en particulier. En lisant les solutions possibles, j'ai fait quelques étapes comme:

• Recherche de fichiers orphelins: personne n'existait;
• exécuter:: show full tables in database;n'a pas vu le problème;
• exécuter describe table;:: retourné table doesn't exist;
• exécuter SELECT * FROM information_schema.TABLES WHERE TABLE_NAME='table';:: retourné Empty set;
• Recherchez manuellement par phpMyAdmin la requête ci-dessus: n'existe pas;

Et, après ces étapes, je vérifie à nouveau avec show tables;et ... vualá! la table problématique avait disparu. Je pourrais le créer et le déposer avec le même nom problématique sans problème, et je n'ai même pas eu à redémarrer le serveur! Bizarre...