La table MySQL n'existe pas d'erreur, mais existe
Est-ce que quelqu'un sait dans quelles conditions vous pouvez recevoir une erreur 1146: Table '<database>.<table>' doesn't exist alors que votre table existe?
J'utilise le même code sur 5 serveurs. Seul celui que j'ai récemment loué affiche cette erreur. Je suppose donc qu'il peut s'agir d'une erreur d'installation ou de configuration. Je peux très bien exécuter mon instruction SQL à partir de la ligne de commande. Je peux évidemment voir le tableau à partir de la ligne de commande également. Je ne reçois aucune erreur de connexion lorsque j'établis une connexion (j'utilise mysqli, btw).
Toute aide serait appréciée.
requête exacte:
$sql = "SELECT DISTINCT(mm_dic_Word) AS Word FROM spider.mm_dictionary WHERE mm_dic_deleted=0";
Fondamentalement, je pense que le problème que je rencontrais était dû à des longueurs de hachage de mot de passe différentes. Dans mon cas, j’ai eu un nouveau serveur, j’ai fait un dump complet de mysql qui a également transféré les mots de passe et les informations de l’utilisateur. Le nouveau serveur était déjà initialisé avec un utilisateur root doté d'un hachage de 16 caractères, mais mon ancien serveur utilisait les plus récentes valeurs de hachage de 32 caractères.
Je devais aller dans my.conf. Régler l'ancien paramètre de mot de passe sur 0 (autrement, chaque fois que j'essayais de mettre à jour la base de données, la nouvelle mise à jour faisait 16 caractères de long). J'ai ensuite mis à jour tous les mots de passe pour qu'ils soient identiques via la commande UPDATE mysql.user SET password=PASSWORD('password here');, puis j'ai supprimé les privilèges.
Évidemment, avoir tous les utilisateurs avec le même mot de passe est une très mauvaise idée, aussi je les ai changés un par un après avoir confirmé que cela fonctionnait.
J'ai tapé une entrée de blog qui décrit certaines des choses que j'ai faites et qui n'ont pas fonctionné ici , avant de tomber sur cette solution (juste au cas où un ou plusieurs de ces changements affectent mon résultat), cependant, pense que la solution ci-dessus est complète ... mais je n'ai pas essayé de reproduire l'erreur, donc je ne peux pas être sûr à 100%.
Cela m'est juste arrivé et après un moment, j'ai trouvé la réponse sur un article de blog et je voulais la mettre ici aussi.
Si vous copiez le répertoire de données MySQL de /var/lib/mysql à /path/to/new/dir, mais que vous copiez uniquement les dossiers de la base de données (c.-à-d. mysql, wpdb, ecommerce, etc.) ET que vous ayez des tables innodb, vos tables innodb s'afficheront dans 'show tables' mais leurs requêtes (select et describe) échouera avec l'erreur Mysql error: table db.tableName doesn't exist. Vous verrez le fichier .frm dans le répertoire db et vous vous demanderez pourquoi.
Pour les tables innodb, il est important de copier les fichiers ib*, qui dans mon cas étaient ibdata1, ib_logfile0 et ib_logfile1. Une fois que j'ai effectué le transfert en veillant à les copier, tout a fonctionné comme prévu.
Si votre fichier my.cnf contient "innodb_file_per_table", le fichier .ibd sera présent dans le répertoire db mais vous aurez toujours besoin des fichiers ib *.
Dans ce cas, il serait bon d'utiliser mysqlcheck - vous pourrez ainsi éliminer les problèmes de santé de la table et les réparer si nécessaire.
Se pourrait-il que votre seul serveur soit une boîte Linux? Mysql est sensible à la casse sur Linux mais insensible à Windows.
J'ai eu ce genre de comportement une fois. Plus tard, j'ai découvert que le pilote JDBC que j'avais utilisé changeait ma requête en minuscule; je ne pouvais donc pas accéder à ma base de données (qui utilisait des lettres en majuscules), bien que mon code utilise les bonnes lettres mélangées.
Cela m’est arrivé lorsque j’essayais de sélectionner une table avec UPPERCASE et que le nom de la table était en minuscule.
Donc, pour résoudre cette question, j'ai mis "lower_case_table_names = 1" sur le fichier my.cnf.
Si vous êtes connecté en tant que personne qui n'est pas autorisée à afficher cette base de données/table, vous obtiendrez probablement ce résultat. Utilisez-vous le même identifiant sur la ligne de commande que vous utilisez mysqli?
Cela pourrait être lié au fait d'avoir des tables InnoDB et MyISAM ensemble. Si vous copiez les fichiers de base de données, MyISAM ira bien et InnoDB s'affichera mais ne fonctionnera pas.
J'ai vu cela sur un système centos 6.4 avec mysql 5.1 et un système de fichiers xfs.
Les tables montrent avec 'show tables' mais une sélection ou une description échoue avec le message de table qui n'existe pas, comme vous l'avez décrit. Les fichiers sont où je m'attends à ce qu'ils soient.
Le système fonctionnait correctement pendant des mois, puis après un redémarrage du service mysqld après avoir modifié le fichier /etc/my.cnf afin de définir table_cache sur 512 au lieu de 256, il est passé de côté.
Selon arcconf, le contrôleur raid pense que tout va bien. xfs_check ne trouve rien. la liste d'événements-système d'IPMI est claire. dmesg montre certaines plaintes de iptables concernant le suivi de la connexion et la suppression de paquetages; nous avons donc peut-être été sous DOS, mais comme rien ne tourne vraiment au serveur, je ne vois pas en quoi cela pourrait affecter l'intégrité des données mysql?
J'ai fini par promouvoir l'esclave à maîtriser et à recharger le système, et je me demande maintenant ce qui pourrait avoir causé l'erreur, et si le choix de xfs sur centos 6.4 est toujours un choix stable, ou si le coupable était mysql 5.1.
Oh oui et ne changez jamais un système en marche :)
Mac OS X? STOP, ne recopiez rien encore ...
J'ai eu ce problème à quelques reprises sur Mavericks. MySQL n'est plus inclus, mais mon installation est essentiellement la même que celle que vous vous attendriez à trouver sur Snow Leopard, je pense, plutôt que MAMP ou quelque chose du genre.
Après avoir migré d'un ordinateur à un autre, j'ai eu ce problème. C'est le résultat du panneau de contrôle de MySQL qui a démarré mysqld, plutôt que de le lancer en ligne de commande. (Lors de la migration, ce panneau de configuration quelque peu obsolète oublie que vous ne lui avez pas dit de ne pas démarrer au démarrage.)
Examinez les processus (moniteur principal ou moniteur d’activité) sur mon système: si le propriétaire est root, il a été lancé par lancé et ne fonctionne pas correctement; le processus correct aura _mysql en tant que propriétaire.
Parfois, j'ai les deux processus en cours d'exécution côte à côte!
Bizarrement, vous pouvez tout faire, y compris utiliser mysql via une ligne de commande. Cependant, même si les tables innodb sont répertoriées, elles génèrent une erreur inexistante lors de l'interrogation.
Cela semble être un problème de propriété, qui peut également s’appliquer à d’autres systèmes.