MySQL> La tabla no existe. Pero lo hace (o debería)

Cambié el datadir de una instalación de MySQL y todas las bases se movieron correctamente, excepto una. Me puedo conectar y USEla base de datos. SHOW TABLESTambién me devuelve todas las tablas correctamente, y los archivos de cada tabla existen en el directorio de datos MySQL.

Sin embargo, cuando trato de hacer SELECTalgo de la tabla, recibo un mensaje de error de que la tabla no existe. Sin embargo, esto no tiene sentido ya que pude mostrar la misma tabla a través de una SHOW TABLESdeclaración.

Mi conjetura es que SHOW TABLESenumera la existencia del archivo pero no comprueba si un archivo está dañado o no. En consecuencia, puedo enumerar esos archivos pero no acceder a ellos.

Sin embargo, es simplemente una suposición. Nunca he visto esto antes. Ahora, no puedo reiniciar la base de datos para la prueba, pero todas las demás aplicaciones que la utilizan funcionan bien. Pero eso es solo una suposición, nunca había visto esto antes.

¿Alguien sabe por qué ocurre esto?

Ejemplo:

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

Por si a alguien todavía le importa:

Tuve el mismo problema después de copiar un directorio de base de datos directamente usando el comando

cp -r /path/to/my/database /var/lib/mysql/new_database

Si hace esto con una base de datos que usa InnoDBtablas, obtendrá este error loco de "tabla no existe" mencionado anteriormente.

El problema es que necesita los ib*archivos en la raíz del datadir MySQL (por ejemplo ibdata1, ib_logfile0y ib_logfile1).

Cuando los copié, funcionó para mí.

Para mí en Mac OS (instalación de MySQL DMG) un simple reinicio del servidor MySQL resolvió el problema. Supongo que la hibernación lo causó.

Recibo este problema cuando el caso del nombre de la tabla que estoy usando está desactivado. Entonces, la tabla se llama 'db' pero usé 'DB' en la instrucción select. Asegúrese de que el caso sea el mismo.

Este error también puede producirse cuando se configura lower_case_table_namesa 1, y luego tratar de tablas de acceso que se crearon con el valor por defecto para esa variable. En ese caso, puede revertirlo al valor anterior y podrá leer la tabla.

1. deja de mysqld
2. copia de seguridad de la carpeta mysql: cp -a /var/lib/mysql /var/lib/mysql-backup
3. Copie la carpeta de la base de datos de la máquina anterior a /var/lib/mysql
4. anular ib * (ib_logfile *, ibdata) de la base de datos anterior
5. iniciar mysqld
6. volcar la base de datos
7. mysqldump >dbase.mysql
8. detener el servicio mysql
9. eliminar /var/lib/mysql
10. rebautizar /var/lib/mysql-backup a/var/lib/mysql
11. iniciar mysqld
12. crear la base de datos
13. mysqldump < dbase.mysql

Por favor ejecute la consulta:

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'

Desafortunadamente, MySQL permite usar caracteres unicode y no imprimibles en el nombre de la tabla. Si creó sus tablas copiando el código de creación de algún documento / sitio web, existe la posibilidad de que tenga espacio de ancho cero en alguna parte.

Acabo de pasar tres días en esta pesadilla. Idealmente, debe tener una copia de seguridad que pueda restaurar, luego simplemente suelte la tabla dañada. Este tipo de errores pueden causar que su ibdata1 crezca enorme (100 GB + en el tamaño de las tablas modestos)

Si no tiene una copia de seguridad reciente, como si confiara en mySqlDump, entonces sus copias de seguridad probablemente se rompieron silenciosamente en algún momento en el pasado. Tendrá que exportar las bases de datos, lo que por supuesto no puede hacer, porque obtendrá errores de bloqueo mientras ejecuta mySqlDump.

Entonces, como solución alternativa, vaya /var/log/mysql/database_name/y elimine el nombre_tabla. *

Luego, inmediatamente trata de volcar la mesa; hacer esto ahora debería funcionar. Ahora restaure la base de datos a una nueva base de datos y reconstruya las tablas que faltan. Luego volcar la base de datos rota.

En nuestro caso, también recibíamos mysql has gone awaymensajes constantemente a intervalos aleatorios en todas las bases de datos; Una vez que se eliminó la base de datos dañada, todo volvió a la normalidad.

No sé la razón, pero en mi caso resolví simplemente deshabilitar y habilitar la verificación de claves externas

SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;

Tuve el mismo problema y busqué durante 2-3 días, pero la solución para mí fue realmente estúpida.

Reiniciar el mysql

$ sudo service mysql restart

Ahora las tablas se vuelven accesibles.

Ok, esto va a sonar bastante absurdo, pero humoréame.
Para mí, el problema se resolvió cuando cambié mi declaración a esto:

SELECT * FROM `table`

Hice dos cambios
1.) Hice minúscula el nombre de la tabla - ¡Lo sé!
2.) Usó el símbolo de cotización específico = ` : es la clave sobre su TAB

La solución suena absurda, pero funcionó y es sábado por la noche y he estado trabajando desde las 9 am, así que lo tomaré :)

Buena suerte.

Tuve este problema después de actualizar WAMP pero sin tener una copia de seguridad de la base de datos.

Esto funcionó para mí:

1. Detener nuevo WAMP

2. Copie los directorios de la base de datos que necesita y el archivo ibdata1 de la antigua instalación de WAMP

3. Eliminar ib_logfile0yib_logfile1

4. Iniciar WAMP

Ahora debería poder hacer copias de seguridad de sus bases de datos. Sin embargo, después de que su servidor se reinicie nuevamente, todavía tendrá problemas. Así que ahora reinstale WAMP e importe sus bases de datos.

Intente ejecutar la consulta sql para descartar el espacio de tabla antes de copiar el archivo idb:

ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

Copiar archivo idb

ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

Reiniciar MySql

Después de tener que reinstalar MySQL, tuve el mismo problema, parece que durante la instalación, se sobrescriben algunos archivos de configuración que almacenan datos sobre los archivos de registro de InnoDB, estos archivos ib_logfile * (¿son archivos de registro?). Para resolver este problema, acabo de eliminar los archivos ib_logfile *.

Lo que funcionó para mí fue simplemente dejar caer la mesa, a pesar de que no existía. Luego volví a crear la tabla y la volví a llenar de un volcado de sql hecho anteriormente.

Debe haber alguna metabase de nombres de tabla, y probablemente todavía existía allí hasta que la solté.

Tuve un problema similar con una mesa fantasma. Afortunadamente, tuve un volcado de SQL antes de la falla.

En mi caso, tuve que:

1. Detener mySQL
2. Mover archivos ib * de /var/mysql off a una copia de seguridad
3. Eliminar /var/mysql/{dbname}
4. Reiniciar mySQL
5. Recrea la base de datos vacía
6. Restaurar archivo de volcado

NOTA: Requiere un archivo de volcado.

1. Hacer mysqldump a la base de datos:

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

2. Restaurar base de datos

   mysql -u user -ppass dbname < D:\Back-ups\dbname.sql

Ahora todas las tablas en la base de datos se restauraron por completo. Tratar..

SELECT * FROM dbname.tablename;

Instalé MariaDB en la nueva computadora, detuve el servicio Mysql y renombré la carpeta de datos a datos. Resolví mi problema copiando solo Mysql \ data \ table_folders e ibdata1 de la carpeta de datos HD a la nueva carpeta de datos mysql instalada.

Me salté ib_logfile0 e ib_logfile1 (de lo contrario, el servidor no inició el servicio)

Se inició el servicio mysql.

Entonces el servidor se está ejecutando.

Parece que el problema tiene que ver (al menos en el mío y en algunos otros) con archivos de registro innodb no válidos (¿corruptos?). En términos generales, simplemente necesitan ser recreados.

Aquí hay soluciones, la mayoría de las cuales requieren un reinicio de mysql.

• Recree sus archivos de registro ( elimine y reinicie mysql )
• Cambie el tamaño de sus archivos de registro (MySql 5.6+ regenerará el archivo por usted)
• Si está realizando algún tipo de migración de datos, asegúrese de haber migrado correctamente el archivo correcto y le haya dado los permisos, como ya han dicho otros.
• Compruebe los permisos de sus datos y archivos de registro, que mysql es propietario de ambos
• Si todo lo demás falla, es probable que deba volver a crear la base de datos

Aquí hay otro escenario (actualización de versión) :

Reinstalé mi sistema operativo (Mac OS El Captain) e instalé una nueva versión de mysql (usando homebrew). La versión instalada (5.7) resultó ser más nueva que la anterior. Luego copié las tablas, incluidos los archivos ib *, y reinicié el servidor. Pude ver las tablas en mysql workbench pero cuando intenté seleccionar algo, obtuve "La tabla no existe".

Solución:

1. detener el servidor mysql, por ejemplo, mysql.server stopobrew services stop mysql
2. inicie el servidor usando mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/(cambie la ruta según sea necesario)
3. ejecutar mysql_upgrade -u root -p password(en otra ventana de terminal)
4. apague el servidor en ejecución mysqladmin -u root -p password shutdown
5. reiniciar el servidor en modo normal mysql.server startobrew services start mysql

Los documentos relevantes están aquí .

En mi caso, definí un disparador en la tabla y luego intenté insertar la fila en la tabla. Parece que, de alguna manera, el disparador era erróneo y, por lo tanto, la inserción estaba dando un error, la tabla no existe.

Es posible que tenga un carácter oculto en el nombre de su tabla. Esos no aparecen cuando haces un show de tablas. ¿Puedes hacer un "SHOW CREATE TABLE TABLE_ONE" y completar la pestaña "TABLE_ONE" y ver si incluye caracteres ocultos? Además, ¿ha intentado soltar y rehacer las tablas? Solo para asegurarme de que no hay nada malo con los privilegios y que no hay caracteres ocultos.

Mismo problema exacto después de la importación de la copia de seguridad de TimeMachine. Mi solución fue detener el servidor MySQL y corregir los permisos de lectura y escritura en los archivos ib *.

Otra respuesta que creo que vale la pena mencionar aquí (porque vine aquí con el mismo problema y resultó ser la respuesta para mí):

Verifique que el nombre de la tabla en su consulta esté escrito exactamente igual que en la base de datos.

Es algo obvio y novato, pero cosas como "usuario" versus "usuarios" pueden hacer tropezar a las personas y pensé que sería una respuesta útil tenerla en la lista aquí. :)

En mi caso, cuando estaba importando el archivo sql exportado, recibí un error como que la tabla no existe para la consulta de creación de tabla.

Me di cuenta de que había un guión bajo en el nombre de mi base de datos y mysql estaba poniendo un carácter de escape justo antes de eso.

Así que eliminé ese guión bajo en el nombre de la base de datos, todo funcionó.

Espero que ayude a alguien más también.

Mi tabla había sido renombrada de alguna manera, es ' Customers'decir, con un espacio inicial

Esto significaba

a) se rompieron las consultas

b) la tabla no apareció donde se esperaba en el orden alfabético de mis tablas, lo que en mi pánico significaba que no podía verla.

RENAME TABLE ` Customer` TO `Customer`;

En mi caso fue SQLCA.DBParm parámetro.

solía

SQLCA.DBParm = "Databse = "sle_database.text""

pero debe ser

SQLCA.DBParm = "Database='" +sle_database.text+ "'"

Explicacion:

Vas a combinar tres cadenas:

 1. Database='              -  "Database='"

 2. (name of the database)  - +sle_database.text+

 3. '                       - "'" (means " ' "  without space)

No use espacios en las marcas de cuadrícula. Gracias a mi colega Jan.

Vaya a: xampp\mysql\data\dbname
dentro de dbname tenga el archivo tablename.frm y tablename.ibd.
elimínelo y reinicie mysql e intente nuevamente.

Copie solo el ibdata1archivo de su antiguo directorio de datos. No copiar ib_logfile1o ib_logfile0archivos. Eso hará que MySQL ya no se inicie.

Se cruzó el mismo problema hoy. Este es un problema de mysql "Identifier Case Sensitivity".

Por favor verifique el archivo de datos correspondiente. Es muy probable que el nombre del archivo esté en minúscula en el sistema de archivos, pero el nombre de la tabla que figura en el comando "mostrar tablas" está en mayúscula. Si la variable del sistema " lower_case_table_names" es 0, la consulta devolverá "la tabla no existe" porque las comparaciones de nombres distinguen entre mayúsculas y minúsculas cuando " lower_case_table_names" es 0.

Tuve el mismo problema en Windows. Además de copiar los archivos ib * y el directorio mysql en el directorio de datos thd, también tuve que hacer coincidir el archivo my.ini.

El archivo my.ini de mi instalación anterior no tenía la siguiente línea:

innodb-page-size=65536

Pero mi nueva instalación sí. Posiblemente porque no tenía esa opción en el instalador anterior. Eliminé esto y reinicié el servicio y las tablas funcionaron como se esperaba. En resumen, asegúrese de que el nuevo archivo my.ini sea una réplica del anterior, con la única excepción del datadir, el plugin-dir y el número de puerto, dependiendo de su nueva instalación.