Tabla MySQL de Schrödingers: existe, pero no

Estoy cometiendo el error más extraño de todos.

A veces, al crear o modificar tablas, aparece el error "la tabla ya existe". Sin embargo, DROP TABLE devuelve '# 1051 - tabla desconocida'. Así que tengo una mesa que no puedo crear, no puedo dejarla.

Cuando intento eliminar la base de datos, mysqld falla. A veces ayuda crear otra base de datos con un nombre diferente, a veces no.

Utilizo una base de datos con ~ 50 tablas, todas InnoDB. Este problema ocurre con diferentes tablas.

Experimenté esto en Windows, Fedora y Ubuntu, MySQL 5.1 y 5.5. Mismo comportamiento, cuando se usa PDO, PHPMyAdmin o línea de comandos. Utilizo MySQL Workbench para administrar mi esquema; vi algunos errores relacionados (líneas finales y demás), sin embargo, ninguno de ellos fue relevante para mí.

No, no es una vista, es una mesa. Todos los nombres están en minúsculas.

Intenté todo lo que pude en Google: vaciar tablas, mover archivos .frm de db a db, leer el registro de mysql, nada ayudó más que reinstalar toda la maldita cosa.

'Mostrar tablas' no revela nada, 'describir' la tabla dice 'la tabla no existe', no hay un archivo .frm, pero 'crear tabla' todavía termina con un error (y también 'crear tabla si no existe') y la caída de la base de datos bloquea mysql

Preguntas relacionadas, pero inútiles:

• Mysql 1050 Error "La tabla ya existe" cuando en realidad no

• La tabla MySQL no existe error, pero existe

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'

Y eso, de todos modos: la tabla no existe, pero no se puede crear;

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

Los nombres cambian, esta no es la única tabla / base de datos con la que he tenido problemas

He visto este problema cuando falta el archivo de datos en el directorio de datos, pero el archivo de definición de tabla existe o viceversa. Si está utilizando innodb_file_per_table, verifique el directorio de datos para asegurarse de tener un .frmarchivo y un archivo .ibd para la tabla en cuestión. Si es MYISAM, debería haber un .frm, .MYIy un .MYDarchivo.

El problema generalmente se puede resolver eliminando el archivo huérfano manualmente.

Haciendo una suposición salvaje aquí, pero parece que innodb todavía tiene una entrada para sus tablas en un espacio de tabla, probablemente en ibdata. Si realmente no necesita ninguno de los datos, o si tiene copias de seguridad, intente lo siguiente:

1. Eliminar todos los esquemas (excepto mysql)
2. cerrar la base de datos
3. Asegúrese de que todas las carpetas en su directorio de datos se hayan eliminado correctamente (nuevamente, excluyendo mysql)
4. eliminar ibdata y archivos de registro
5. reinicie la base de datos. Debería recrear el espacio de tabla y los registros desde cero.

La solución resulta fácil; al menos lo que resolví, funcionó para mí. Cree una tabla "zzz" en otra instancia de MySQL, donde zzz es el nombre de la tabla del problema. (es decir, si la tabla se llama schrodinger, sustitúyala por zzz donde sea que esté escrito). No importa cuál sea la definición de la tabla. Es un maniquí temporal; Copie el archivo zzz.frm en el directorio de la base de datos en el servidor donde debería estar la tabla, asegurándose de que la propiedad y los permisos del archivo sean correctos en el archivo. En MySQL, ahora puede hacer "mostrar tablas", y la tabla zzz estará allí. mysql> eliminar tabla zzz; ... ahora debería funcionar. Borre los archivos zzz.MYD o ZZZ.MYI del directorio si es necesario.

Dudo que esta sea una respuesta directa al caso de la pregunta aquí, pero así es como resolví este problema exacto percibido en mi sistema OS X Lion.

Con frecuencia creo / elimino tablas para algunos trabajos de análisis que he programado. En algún momento, comencé a obtener errores de tabla ya existentes a la mitad de mi script. Un reinicio del servidor generalmente resolvía el problema, pero esa era una solución demasiado molesta.

Luego noté en el archivo de registro de errores local esta línea en particular:

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

Esto me dio la idea de que tal vez si mis tablas contuvieran letras mayúsculas, MySQL se engañaría pensando que todavía están allí incluso después de haberlas dejado caer. Ese resultó ser el caso y cambiar a usar solo letras minúsculas para los nombres de las tablas hizo que el problema desapareciera.

Es probable que sea el resultado de una mala configuración en mi caso, pero espero que este caso de error ayude a alguien a perder menos tiempo tratando de encontrar una solución.

Esta es una pregunta antigua, pero acabo de encontrar el mismo problema y una respuesta en uno de los problemas relacionados vinculados en la parte superior era justo lo que necesitaba y mucho menos drástico que eliminar archivos, tablas, apagar el servidor, etc.

mysqladmin -uxxxxxx -pyyyyy flush-tables

En mi caso, el problema se resolvió cambiando la propiedad del directorio de datos mysql al usuario que ejecutó la aplicación. (En mi caso, era una aplicación Java que ejecutaba el servidor web Jetty).

Aunque mysql se estaba ejecutando y otras aplicaciones podían usarlo correctamente, esta aplicación tenía un problema con eso. Después de cambiar la propiedad del directorio de datos y restablecer la contraseña del usuario, todo funcionó correctamente.

Si hay existencias con este error 1051 y solo desea eliminar la base de datos e importar esto nuevamente, siga estos pasos y todo estará bien ...

en entorno Unix como root :

• rm -rf / var / lib / mysql / YOUR_DATABASE;
• OPCIONAL -> mysql_upgrade --force
• mysqlcheck -uUSER -pPASS YOUR_DATABASE
• mysqladmin -uUSER -pPASS suelta YOUR_DATABASE
• mysqladmin -uUSER -pPASS crea YOUR_DATABASE
• mysql -uUSER -pPASS YOUR_DATABASE <IMPORT_FILE

Saludos, Christus

Tuve este problema y esperaba que eliminar el archivo IBD ayudara como se publicó anteriormente, pero no hizo ninguna diferencia. MySQL solo recreó un nuevo archivo IBD. En mi caso, existen tablas similares en otras bases de datos en la misma instancia de MySQL. Como faltaba el archivo FRM, copié el archivo FRM de la tabla similar en otra base de datos, reinicié MySQL y la tabla funcionó correctamente.

Me encontré con este error después de crear una tabla y eliminarla, luego quise crearla nuevamente. En mi caso, tenía un archivo de volcado autónomo, así que eliminé mi esquema, lo recreé e importé tablas y datos utilizando el archivo de volcado.

Ocurre en nuestro sitio (pero rara vez) generalmente cuando ocurre un "evento" mientras se ejecutan ciertos scripts que reconstruyen mucho. Los eventos incluyen cortes de red o problemas de energía.
Lo que hago para esto en las raras ocasiones en que sucede - uso el enfoque de mano dura:

• Necesitaba simplemente deshacerme de y reconstruir la tabla en particular. Por lo general, estoy en una posición en la que esto está bien ya que se está construyendo la tabla. (Su situación puede ser diferente si necesita recuperar datos)
• Como administrador, vaya a la instalación de mysql (en Windows puede ser "... archivos de programa / mysql / MySQL Server xx / data / <schemaname>
• Busque el archivo ofensivo con el nombre de la tabla en la carpeta <schemaname> y elimínelo.
• Busque archivos temporales huérfanos y elimínelos también. # ... archivos frm si se encuentran allí.
• MySQL te permitirá CREAR la tabla nuevamente

He tenido este problema en un par de bases de datos diferentes durante mucho tiempo (años). Fue un truco por los mensajes contradictorios. La primera vez que hice una variación de la base de datos de eliminación / reconstrucción / cambio de nombre como se describe en las otras respuestas y logré poner las cosas en marcha, pero definitivamente lleva más tiempo de esa manera. Por suerte para mí, siempre ha sucedido con las tablas de referencia que se están reconstruyendo, DROP'd y CREATEd, generalmente por la mañana. Rara vez tuvo el problema, pero llegó a reconocerlo como un caso peculiar y peculiar. (Lo reiteraré: si necesita recuperar los datos, busque las otras soluciones).

• no es una tabla que pertenece a otro usuario, o en otra base de datos
• no es el problema de mayúsculas / minúsculas, uso todo en minúsculas, ¡pero ese fue un tema interesante!
• Fue más frustrante ver respuestas con variaciones de "definitivamente estaba <there / not-there / some-other-user-table-case> y simplemente no lo estás haciendo bien" :)
• la tabla no se mostró en "mostrar tablas"
• la mesa era (siempre fue / había sido) una mesa INNODB.
• intentar DROP the table dio el mensaje de error que la tabla no existe.
• pero intentar CREAR la tabla dio el mensaje de error de que la tabla ya existe.
• usando mysql 5.0 o 5.1
• REPARACIÓN no es eficaz para este problema

Tenía este problema con una mesa en particular. Al leer las posibles soluciones, hice algunos pasos como:

• Búsqueda de archivos huérfanos: no existía nadie;
• ejecutar:: show full tables in database;no vi el problemático;
• ejecutar describe table;:: devuelto table doesn't exist;
• ejecutar SELECT * FROM information_schema.TABLES WHERE TABLE_NAME='table';:: devuelto Empty set;
• Busque por phpMyAdmin manualmente la consulta anterior: no existía;

Y, luego de esos pasos, vuelvo a verificar con el show tables;y ... ¡vualá! la mesa problemática se había ido. Podría crearlo y soltarlo con el mismo nombre problemático sin problemas, ¡y ni siquiera tuve que reiniciar el servidor! Extraño...