MySQL> Table n'existe pas. Mais c'est le cas (ou cela devrait)

J'ai changé le datadir d'une installation MySQL et toutes les bases se sont déplacées correctement sauf une. Je peux me connecter et USEla base de données. SHOW TABLESme renvoie également toutes les tables correctement, et les fichiers de chaque table existent sur le répertoire de données MySQL.

Cependant, lorsque j'essaie de SELECTtrouver quelque chose dans la table, j'obtiens un message d'erreur indiquant que la table n'existe pas. Pourtant, cela n'a pas de sens puisque j'ai pu montrer le même tableau à travers la SHOW TABLESdéclaration.

Je suppose que cela SHOW TABLESrépertorie l'existence du fichier mais ne vérifie pas si un fichier est corrompu ou non. Par conséquent, je peux lister ces fichiers mais ne pas y accéder.

Néanmoins, ce n'est qu'une supposition. Je n'avais jamais vu ça avant. Maintenant, je ne peux pas redémarrer la base de données pour les tests, mais toutes les autres applications qui l'utilisent fonctionnent correctement. Mais c'est juste une supposition, je n'ai jamais vu ça auparavant.

Est-ce que quelqu'un sait pourquoi cela se produit?

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 soucierait encore:

J'ai eu le même problème après avoir copié 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 des InnoDBtables, vous obtiendrez cette folle erreur «la table n'existe pas» mentionnée ci-dessus.

Le problème est que vous avez besoin des ib*fichiers à la racine du datadir MySQL (par exemple ibdata1, ib_logfile0et ib_logfile1).

Quand j'ai copié ceux-ci, cela a fonctionné pour moi.

Pour moi sur Mac OS (installation MySQL DMG), un simple redémarrage du serveur MySQL a résolu le problème. Je suppose que l'hibernation l'a causé.

J'obtiens ce problème lorsque le cas du nom de table 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 boîtier est le même.

Cette erreur peut également se produire lors de la définition lower_case_table_namesde 1, puis lors de l'accès aux tables créées avec la valeur par défaut de cette variable. Dans ce cas, vous pouvez revenir à la valeur précédente et vous pourrez lire le tableau.

1. arrêtez mysqld
2. sauvegarde du dossier mysql: cp -a /var/lib/mysql /var/lib/mysql-backup
3. copier le dossier de la base de données de l'ancienne machine vers /var/lib/mysql
4. remplacer ib * (ib_logfile *, ibdata) de l'ancienne base de données
5. démarrer mysqld
6. vidage de la base de données
7. mysqldump >dbase.mysql
8. arrêter le service mysql
9. retirer /var/lib/mysql
10. renommer /var/lib/mysql-backupen/var/lib/mysql
11. démarrer mysqld
12. créer la base de données
13. 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 le nom de la table. Si vous avez créé vos tableaux en copiant créer du code à partir d'un document / site Web, il y a une chance qu'il ait un espace de largeur nulle quelque part.

Je viens de passer trois jours sur ce cauchemar. Idéalement, vous devriez avoir une sauvegarde que vous pouvez restaurer, puis déposez simplement la table endommagée. Ces sortes d'erreurs peuvent causer votre ibdata1 grandir énorme (100Go + taille pour les tables modestes)

Si vous n'avez pas de sauvegarde récente, comme si vous vous appuyiez sur mySqlDump, vos sauvegardes se sont probablement interrompues silencieusement à un moment donné dans le passé. Vous devrez 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, comme solution de contournement, accédez à /var/log/mysql/database_name/et supprimez le nom_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 la ou les tables manquantes. Vider ensuite la base de données cassée.

Dans notre cas, nous recevions également constamment des mysql has gone awaymessages à 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.

Je ne connais pas la raison mais dans mon cas, j'ai résolu de désactiver et d'activer la vérification des clés étrangères

SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;

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, cela va sembler assez absurde, mais faites-moi plaisir.
Pour moi, le problème a été résolu lorsque j'ai changé ma déclaration en ceci:

SELECT * FROM `table`

J'ai fait deux changements
1.) J'ai fait le nom du tableau en minuscules - je sais !!
2.) Utilisé le symbole de citation spécifique = ` : c'est la clé au-dessus de votre TAB

La solution semble absurde, mais elle a fonctionné et c'est samedi soir et je travaille depuis 9 heures du matin - Alors je vais la prendre :)

Bonne chance.

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:

1. Arrêtez le nouveau WAMP

2. Copiez les répertoires de base de données dont vous avez besoin et le fichier ibdata1 de l'ancienne installation WAMP

3. Supprimer ib_logfile0etib_logfile1

4. Démarrer WAMP

Vous devriez maintenant pouvoir effectuer des sauvegardes de vos bases de données. Cependant, après le redémarrage de votre serveur, vous aurez toujours des problèmes. Alors, réinstallez WAMP et importez vos bases de données.

Essayez d'exécuter la requête SQL pour éliminer l'espace disque logique avant de copier le fichier idb:

ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

Copier le fichier idb

ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

Redémarrez MySql

Après avoir dû réinstaller MySQL, j'ai eu ce même problème, il semble que lors de l'installation, certains fichiers de configuration qui stockent des données sur les fichiers journaux InnoDB, ces fichiers ib_logfile * (ce sont des fichiers journaux à droite?), Sont écrasés. Pour résoudre ce problème, je viens de supprimer les fichiers ib_logfile *.

Ce qui a fonctionné pour moi, c'était simplement de laisser tomber la table, même si elle n'existait pas. Ensuite, j'ai recréé la table et repeuplé à partir d'un vidage SQL effectué précédemment.

Il doit y avoir une métabase de noms de table, et elle existait probablement encore là-bas jusqu'à ce que je la laisse tomber.

Eu un problème similaire avec une table fantôme. Heureusement, il y avait un vidage SQL avant l'échec.

Dans mon cas, j'ai dû:

1. Arrêtez mySQL
2. Déplacer des fichiers ib * /var/mysqlhors d'une sauvegarde
3. Supprimer /var/mysql/{dbname}
4. Redémarrez mySQL
5. Recréer une base de données vide
6. Restaurer le fichier de vidage

REMARQUE: nécessite un fichier de vidage.

1. Faites mysqldump dans la base de données:

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

2. Restaurer 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;

J'ai installé MariaDB sur un nouvel ordinateur, arrêté le service de données Mysql renommé dossier de données en données - j'ai résolu mon problème en copiant seulement Mysql \ data \ table_folders et ibdata1 du dossier de données HD MySql écrasé vers le nouveau dossier de données mysql installé.

J'ai ignoré ib_logfile0 et ib_logfile1 (sinon le serveur n'a pas démarré le service)

Démarrage du service mysql.

Le serveur est alors en cours d'exécution.

Il semble que le problème soit lié (au moins au mien et à quelques autres) à des fichiers journaux innodb invalides (corrompus?). D'une manière générale, il suffit de les recréer.

Voici des solutions, dont la plupart nécessitent un redémarrage de mysql.

• Recréez vos fichiers journaux ( supprimez et redémarrez mysql )
• Redimensionnez vos fichiers journaux (MySql 5.6+ régénérera le fichier pour vous)
• Si vous effectuez un certain type de migration de données, assurez-vous que vous avez correctement migré le bon fichier et lui avez accordé des autorisations comme d'autres l'ont déjà indiqué
• Vérifiez les autorisations de vos données et fichiers journaux, que mysql est propriétaire des deux
• Si tout le reste échoue, vous devrez probablement recréer la base de données

Voici un autre scénario (mise à niveau de version) :

J'ai réinstallé mon OS (Mac OS El Captain) et installé une nouvelle version de mysql (en utilisant homebrew). La version installée (5.7) était plus récente que la précédente. Ensuite, j'ai copié les tables, y compris les fichiers ib *, et redémarré le serveur. Je pouvais voir les tables dans le plan de travail mysql mais quand j'ai essayé de sélectionner quoi que ce soit, j'ai eu "La table n'existe pas".

Solution:

1. arrêter le serveur mysql par exemple mysql.server stopoubrew services stop mysql
2. démarrez le serveur en utilisant mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/(changez le chemin si nécessaire)
3. exécuter mysql_upgrade -u root -p password(dans une autre fenêtre de terminal)
4. arrêtez le serveur en cours d'exécution mysqladmin -u root -p password shutdown
5. redémarrez le serveur en mode normal mysql.server startoubrew services start mysql

Les documents pertinents sont ici .

Dans mon cas, j'avais défini un déclencheur sur la table, puis j'essayais d'insérer la ligne dans la table. semble que le déclencheur était en quelque sorte erroné, et que l'insertion donnait une erreur, la table n'existe pas.

Il est possible que vous ayez un caractère caché dans le nom de votre table. Ceux-ci n'apparaissent pas lorsque vous faites un show tables. Pouvez-vous faire un "SHOW CREATE TABLE TABLE_ONE" et l'onglet compléter le "TABLE_ONE" et voir s'il met des caractères cachés. De plus, avez-vous essayé de supprimer et de refaire les tables. Juste pour vous assurer que les privilèges ne vont pas mal et qu'il n'y a pas de caractères cachés.

Même problème exact après l'importation de la sauvegarde TimeMachine. Ma solution était d'arrêter le serveur MySQL et de corriger les autorisations de lecture-écriture sur les fichiers ib *.

Je pense qu'une autre réponse mérite d'être évoquée ici (parce que je suis venu ici avec le même problème et cela s'est avéré être la réponse pour moi):

Vérifiez que le nom de la table dans votre requête est orthographié exactement de la même manière que dans la base de données.

C'est une chose évidente pour les débutants, mais des choses comme "utilisateur" vs "utilisateurs" peuvent faire trébucher les gens et j'ai pensé que ce serait une réponse utile à avoir dans la liste ici. :)

Dans mon cas, lorsque j'importais le fichier sql exporté, j'obtenais une erreur comme la 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 mysql mettait un caractère d'échappement juste avant cela.

J'ai donc supprimé ce soulignement dans le nom de la base de données, tout a fonctionné.

J'espère que ça aide quelqu'un d'autre aussi.

Ma table avait été renommée en quelque sorte ' Customers'avec un espace de tête

Cela signifiait

a) les requêtes ont éclaté

b) le tableau n'apparaissait pas comme prévu dans l'ordre alphabétique de mes tableaux, ce qui dans ma panique signifiait que je ne pouvais pas le voir!

RENAME TABLE ` Customer` TO `Customer`;

Dans mon cas, c'était un SQLCA.DBParmparamètre.

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 dans les quatermarks. Merci à mon collègue Jan.

Allez à: à l' xampp\mysql\data\dbname
intérieur de dbname ont tablename.frm et tablename.ibd fichier.
supprimez-le et redémarrez mysql et réessayez.

Copiez uniquement le ibdata1fichier de votre ancien répertoire de données. Ne copiez pas ib_logfile1ou ib_logfile0fichiers. Cela empêchera MySQL de démarrer.

Entré croiser le même problème aujourd'hui. Il s'agit d'un problème mysql "Identifier Case Sensitivity".

Veuillez vérifier le fichier de données correspondant. Il est très probable que le nom de fichier soit en minuscules sur le système de fichiers, mais le nom de table répertorié dans la commande "show tables" est en majuscules. Si la variable système " lower_case_table_names" est 0, la requête renverra "la table n'existe pas" car les comparaisons de noms sont sensibles à la casse lorsque " lower_case_table_names" est 0.

J'ai eu le même problème sous Windows. En plus de copier les fichiers ib * et le répertoire mysql sous le répertoire de données thd, j'ai également dû faire correspondre le fichier my.ini.

Le fichier my.ini de mon installation précédente n'avait pas la ligne suivante:

innodb-page-size=65536

Mais ma nouvelle installation l'a fait. Peut-être parce que je n'avais pas cette option dans l'ancien programme d'installation. J'ai supprimé cela et redémarré le service et les tables ont fonctionné comme prévu. En bref, assurez-vous que le nouveau fichier my.ini est une réplique de l'ancien, à la seule exception étant le datadir, le plugin-dir et le port #, selon votre nouvelle installation.