MySQL> La table n'existe pas. Mais ça le fait (ou ça devrait)
J'ai changé le datadir d'une installation MySQL et après quelques étapes cela a bien fonctionné. Chaque base que j'avais avait été déplacée correctement sauf une.
Je peux me connecter et utiliser la base de données, même SHOW TABLES me renvoie toutes les tables correctement et les fichiers de chaque table existent dans le répertoire de données mysql. Mais lorsque j'essaie de sélectionner quelque chose, cela signifie que la table n'existe pas. Mais la table existe, elle apparaît même à l'instruction SHOW TABLES!
Je suppose que SHOW TABLES indique si les fichiers sont corrompus ou quelque chose du genre, mais cela ne le vérifie pas. Je peux donc les lister mais pas y accéder.
Mais ce n'est qu'une hypothèse, je n'ai jamais vu cela auparavant. Impossible de redémarrer la base de données pour le test, toutes les autres applications qui l'utilisent fonctionnent correctement.
Est-ce que quelqu'un sait ce que c'est?
Exemple:
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
Juste au cas où quelqu'un se soucie encore:
J'ai eu le même problème après la copie d'un répertoire de base de données directement à l'aide de la commande
cp -r /path/to/my/database /var/lib/mysql/new_database
Si vous faites cela avec une base de données qui utilise les tables InnoDB, vous obtiendrez cette erreur folle 'la table n'existe pas' mentionnée ci-dessus.
Le problème est que vous avez besoin des fichiers ib* à la racine du répertoire de données MySQL (par exemple, ibdata1, ib_logfile0 et ib_logfile1).
Quand j'ai copié ceux-ci cela a fonctionné pour moi.
Pour moi sur Mac OS (Installation de MySQL DMG), un simple redémarrage du serveur MySQL a résolu le problème. Je devine que l'hibernation a causé cela.
J'ai ce problème lorsque le nom du tableau que j'utilise est désactivé. Donc, la table s'appelle 'db' mais j'ai utilisé 'DB' dans l'instruction select. Assurez-vous que le cas est le même.
Cette erreur peut également se produire lorsque vous définissez lower_case_table_names sur 1, puis que vous essayez d'accéder aux tables créées avec la valeur par défaut pour cette variable. Dans ce cas, vous pouvez rétablir la valeur précédente et lire le tableau.
- arrêtez mysqld
- dossier de sauvegarde mysql:
cp -a /var/lib/mysql /var/lib/mysql-backup - copier le dossier de la base de données de l’ancien ordinateur vers
/var/lib/mysql - remplacer ib * (ib_logfile *, ibdata) de l'ancienne base de données
- démarrer mysqld
- dump dabase
mysqldump >dbase.mysql- arrêter le service mysql
- supprimer
/var/lib/mysql - renommer
/var/lib/mysql-backupen/var/lib/mysql - démarrer mysqld
- créer la base de données
mysqldump < dbase.mysql
Veuillez exécuter la requête:
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'
Malheureusement, MySQL autorise l'utilisation de caractères unicode et non imprimables dans nom de table . Si vous avez créé vos tables en copiant le code créé à partir d'un document/site Web, il est possible qu'il ait quelque part zéro largeur.
Je viens de passer trois jours sur ce cauchemar. Idéalement, vous devriez avoir une sauvegarde que vous pouvez restaurer, puis simplement supprimer la table endommagée. Ces erreurs peuvent entraîner la croissance de votre ibdata1 énorme (taille supérieure à 100 Go pour les tables modestes)
Si vous ne disposez pas d'une sauvegarde récente, par exemple si vous vous êtes fondé sur mySqlDump, vos sauvegardes se sont probablement brisées en silence à un moment donné dans le passé. Vous aurez besoin d'exporter les bases de données, ce que vous ne pouvez bien sûr pas faire, car vous obtiendrez des erreurs de verrouillage lors de l'exécution de mySqlDump.
Donc, pour contourner le problème, accédez à /var/log/mysql/database_name/ et supprimez le nom de la table. *
Ensuite, essayez immédiatement de vider la table; cela devrait maintenant fonctionner. Maintenant, restaurez la base de données dans une nouvelle base de données et reconstruisez les tables manquantes. Puis videz la base de données cassée.
Dans notre cas, nous recevions aussi constamment des messages mysql has gone away à intervalles aléatoires sur toutes les bases de données; une fois la base de données endommagée supprimée, tout est revenu à la normale.
J'ai eu le même problème et j'ai cherché pendant 2-3 jours, mais la solution pour moi était vraiment stupide.
Redémarrez le mysql
$ Sudo service mysql restart
Maintenant, les tables deviennent accessibles.
D'accord. ça va paraître assez absurde, mais humour moi.
Pour moi, le problème a été résolu lorsque j'ai modifié ma déclaration en ceci:
SELECT * FROM `table`
J'ai fait deux changements
1.) Fait le nom de la table minuscule - je sais !!
2..) Utilisez le symbole de citation spécifique = `: C'est la clé au-dessus de votre tabulation
La solution semble absurde, mais cela a fonctionné et nous sommes samedi soir et je travaille depuis 9 heures - Alors je vais le prendre :)
Bonne chance.
Essayez d’exécuter une requête sql pour supprimer le tablespace avant de copier le fichier idb:
ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;
Copier le fichier idb
ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;
Redémarrer MySql
Eu un problème similaire avec une table fantôme. Heureusement, il y a eu un vidage SQL d'avant l'échec.
Dans mon cas, je devais:
- Arrêtez MySQL
- Déplacez les fichiers ib * de
/var/mysqlvers une sauvegarde - Supprimer
/var/mysql/{dbname} - Redémarrer mySQL
- Recréer une base de données vide
- Restaurer le fichier de vidage
REMARQUE: nécessite un fichier de vidage.
Après avoir dû réinstaller MySQL, je rencontrais le même problème. Lors de l’installation, certains fichiers de configuration stockant des données sur les fichiers journaux InnoDB, ces fichiers ib_logfile * (ce sont des fichiers journaux non?), Sont écrasés. Pour résoudre ce problème, je viens de supprimer les fichiers ib_logfile *.
J'ai eu ce problème après la mise à niveau de WAMP mais sans sauvegarde de base de données.
Cela a fonctionné pour moi:
Arrêtez le nouveau WAMP
Copiez les répertoires de base de données dont vous avez besoin et le fichier ibdata1 de l'ancienne installation de WAMP.
Supprimer
ib_logfile0etib_logfile1Démarrer WAMP
Vous devriez maintenant pouvoir faire des sauvegardes de vos bases de données. Cependant, après le redémarrage de votre serveur, vous aurez toujours des problèmes. Alors maintenant, réinstallez WAMP et importez vos bases de données.
Je ne connais pas la raison, mais dans mon cas, j'ai résolu simplement de désactiver et d'activer la vérification des clés étrangères
SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;
Ce qui a fonctionné pour moi, c’était de laisser tomber la table, même si elle n’existait pas. Ensuite, j'ai re créé la table et repeuplé à partir d'un dump SQL effectué précédemment.
Il doit exister une métabase de noms de table, et elle existait probablement encore jusqu'à son abandon.
Faites mysqldump à la base de données:
mysqldump -u user -ppass dbname > D:\Back-ups\dbname.sqlRestaurer la base de données
mysql -u user -ppass dbname < D:\Back-ups\dbname.sql
Maintenant, toutes les tables de la base de données ont été complètement restaurées. Essayer..
SELECT * FROM dbname.tablename;
Il semble que le problème concerne (du moins dans le mien et quelques autres) des fichiers journaux innodb non valides (corrompus?). De manière générale, ils doivent simplement être recréés.
Voici des solutions, dont la plupart nécessitent un redémarrage de mysql.
- Recréez vos fichiers de log ( Supprimez et redémarrez mysql )
- Redimensionnez vos fichiers journaux (MySql 5.6+ régénérera le fichier pour vous)
- Si vous effectuez un type de migration de données, assurez-vous que vous avez correctement migré le bon fichier et que vous lui accordez les autorisations correspondantes.
- Vérifiez les permissions de vos données et fichiers de log, que mysql est propriétaire des deux
- Si tout échoue, vous devrez probablement recréer la base de données
Voici un autre scénario (mise à niveau de la version):
J'ai réinstallé mon système d'exploitation (Mac OS El Captain) et installé une nouvelle version de mysql (en utilisant homebrew). La version installée (5.7) s’est avérée être plus récente que la précédente. Ensuite, j'ai copié sur les tables, y compris les fichiers ib *, puis redémarré le serveur. Je pouvais voir les tables dans mysql workbench mais quand j'ai essayé de sélectionner quoi que ce soit, j'ai eu "La table n'existe pas".
Solution:
- arrêtez le serveur mysql, par exemple
mysql.server stopoubrew services stop mysql - démarrez le serveur en utilisant
mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/(changez le chemin si nécessaire) - lancer
mysql_upgrade -u root -p password(dans une autre fenêtre de terminal) - arrêter le serveur en cours
mysqladmin -u root -p password shutdown - redémarrez le serveur en mode normal
mysql.server startoubrew services start mysql
Les documents pertinents sont ici .
Aller à: xampp\mysql\data\dbname
inside nombase a tablename.frm et le fichier nomtable.ibd.
supprimez-le .__, redémarrez mysql et réessayez.
Dans mon cas, il s'agissait du paramètre SQLCA.DBParm.
J'ai utilisé
SQLCA.DBParm = "Databse = "sle_database.text""
mais ça doit être
SQLCA.DBParm = "Database='" +sle_database.text+ "'"
Explication:
Vous allez combiner trois chaînes:
1. Database=' - "Database='"
2. (name of the database) - +sle_database.text+
3. ' - "'" (means " ' " without space)
N'utilisez pas d'espaces en quatermarks. Merci à mon collègue Jan.
Dans mon cas, j’avais défini un déclencheur sur la table et essayais ensuite d’insérer la ligne dans la table. semble que, de toute façon, le déclencheur était erroné, et par conséquent, insérer donnait une erreur, la table n’existait pas.
Entré traverser le même problème aujourd'hui. C'est un problème de mysql "Sensibilité à la casse de l'identifiant".
Veuillez vérifier le fichier de données correspondant. Il est très probable que le nom de fichier soit en minuscule sur le système de fichiers mais que le nom de la table répertorié dans la commande "show tables" le soit en majuscule. Si la variable système "lower_case_table_names" a la valeur 0, la requête renvoie "la table n'existe pas" car les comparaisons de noms sont sensibles à la casse lorsque "lower_case_table_names" a la valeur 0.
Copiez uniquement le fichier ibdata1 à partir de votre ancien répertoire de données. Ne copiez pas les fichiers ib_logfile1 ou ib_logfile0. Cela fera que MySQL ne démarrera plus.
Il est possible que vous ayez un caractère caché dans le nom de votre table. Ceux-ci n'apparaissent pas lorsque vous faites une table de spectacle. Pouvez-vous faire un "SHOW CREATE TABLE TABLE_ONE" et onglet compléter le "TABLE_ONE" et voir si il met des caractères cachés. Aussi, avez-vous essayé de laisser tomber et de refaire les tables. Juste pour m'assurer que les privilèges et les privilèges sont bien présents et qu'il n'y a pas de caractères cachés.
Dans mon cas, lors de l’importation du fichier SQL exporté, j’obtenais une erreur telle que table n'existe pas pour la requête de création de table.
J'ai réalisé qu'il y avait un trait de soulignement dans le nom de ma base de données et que mysql mettait un caractère d'échappement juste avant.
J'ai donc supprimé le trait de soulignement dans le nom de la base de données, tout a fonctionné.
J'espère que ça aide quelqu'un d'autre aussi.
Une autre réponse qui, je pense, mérite d'être évoquée ici (car je suis venue ici avec le même problème et cela s'est avéré être la réponse pour moi):
Vérifiez deux fois que le nom de la table dans votre requête est orthographié exactement de la même manière tel qu’il est dans la base de données.
C'est une évidence, un débutant, mais des choses comme "utilisateur" ou "utilisateurs" peuvent faire trébucher les gens et j'ai pensé que ce serait une réponse utile d'avoir la liste ici. :)
Même problème après l'importation de la sauvegarde Time Machine. Ma solution consistait à arrêter le serveur MySQL et à corriger les autorisations de lecture-écriture sur les fichiers ib *.
Il vous manque un caractère sur votre table lorsque vous le tapez. Procédez comme suit:
mysql> show tables;
+-----------------------+
| Tables_in_database |
+-----------------------+
| TABLE_ONE | Double click on TABLE_ONE and copy*
| TABLE_TWO | (*You'd get the correct string)
| TABLE_THREE |
+-----------------------+
mysql> SELECT * paste_your_copied_table;
Si les tables sont affichées dans mysql, elles existent. Cela devrait marcher!
Ma table avait en quelque sorte été renommée en ' Customers' c'est-à-dire avec un espace de début
Cela signifiait
a) des requêtes ont éclaté
b) la table n'apparaissait pas comme prévu dans l'ordre alphabétique de mes tables, ce qui, dans mon panique signifiait que je ne pouvais pas la voir!
RENAME TABLE ` Customer` TO `Customer`;
J'ai eu le même problème, mais ce n'était pas dû à un personnage caché ou à "la table de Schroedinger". Le problème (exactement comme indiqué ci-dessus) est apparu après un processus de restauration. J'utilise la version 1.2.16 de l'administrateur MySQL. Lorsqu'une restauration doit être effectuée, vous devez décocher ORIGINAL dans le schéma cible et sélectionner le nom de votre base de données dans la liste déroulante. Après cela, le problème a été corrigé. Au moins c'était la raison dans ma base de données.
S'il y a un point dans le nom de la table, il échouera pour
SELECT * FROM poorly_named.table;
Utilisez des backticks pour le trouver et trouver la table
SELECT * FROM `poorly_named.table`;
Dans mon cas, je l’ai eu sans faire de déménagement de datadir ni manipuler aucun type de fichier. C'est arrivé un beau matin.
Comme, curieusement, j’ai pu vider la table, en utilisant mysqldump, même si MySQL se plaignait parfois de "table n'existe pas", je l'ai résolu en vidant le schéma + les données de la table, puis CREEZ-le immédiatement après, suivi d'une importation.