2010-11-23 132 views
19

¿Alguien sabe bajo qué condiciones puede recibir un error 1146: Table '<database>.<table>' doesn't exist cuando su tabla, de hecho, existe?MySQL Table no existe error, pero existe

Uso el mismo código en 5 servidores, solo uno que alquilé recientemente muestra este error, así que sospecho que puede tratarse de una configuración o error de instalación de algún tipo. Puedo ejecutar mi instrucción sql desde la línea de comandos sin problemas. Obviamente, puedo ver la mesa desde la línea de comando. No obtengo ningún error de conexión cuando establezco una conexión (estoy usando mysqli, btw).

Cualquier ayuda sería apreciada.

consulta exacta:

$sql = "SELECT DISTINCT(mm_dic_word) AS word FROM spider.mm_dictionary WHERE mm_dic_deleted=0"; 
+0

¿Puede mostrarnos la consulta exacta de la que está obteniendo este problema? –

+0

sí, ¿dónde está la consulta? – luckytaxi

+0

¿Se puede llegar a la base de datos usando la terminal? –

Respuesta

2

Básicamente, creo que el problema que estaba experimentando se debía a las diferentes longitudes de hash de contraseñas. En mi caso, obtuve un nuevo servidor, hice un volcado de MySQL completo que transfería contraseñas e información de usuario también. El nuevo servidor ya se había inicializado con un usuario raíz que tenía un hash de longitud de 16 caracteres, pero mi servidor anterior usaba las últimas 32 longitudes de hash de caracteres.

Tuve que entrar en my.conf establecí la configuración de contraseñas antiguas en 0 (de otra forma cada vez que traté de actualizar la base de datos, la nueva actualización tenía 16 caracteres de longitud). Luego, actualicé todas las contraseñas para que fueran las mismas a través del comando UPDATE mysql.user SET password=PASSWORD('password here');, luego cerré los privilegios.

Obviamente, tener a todos los usuarios con la misma contraseña es una muy mala idea, así que los cambié uno por uno después de confirmar que funcionaba.

Escribí una entrada de blog que se dedica a algunas de las otras cosas que hice que no funcionó here, antes de encontrar esta solución (en caso de que uno o más cambios afectaran mi resultado) sin embargo, Creo que la solución anterior está completa ... pero no he intentado reproducir el error, así que no puedo estar 100% seguro.

2

Podría ser que su un servidor es una máquina Linux? Mysql es sensible a mayúsculas y minúsculas en Linux, pero insensible en Windows.

+0

Todos ellos son cuadros de Linux, este es CentOS, todos los demás son Debian ... no sé si eso ayuda. Por supuesto, puedo ejecutar el sql a través de mi espejo de prueba local, que es Windows, por lo que no es un problema de caso. –

1

Tuve este tipo de comportamiento una vez. Más tarde descubrí que el controlador JDBC que utilicé cambió mi consulta a minúsculas, por lo que no pude acceder a mi base de datos (que usaba mayúsculas y minúsculas), aunque mi código usaba las letras mixtas correctas.

+0

Ojalá fuera así de simple ... Siempre utilizo minúsculas por estos motivos. –

+0

que es exactamente lo que está sucediendo con * me *, me gustaría que fuera tan simple como que realmente hayas publicado cómo resolviste ese problema aquí. –

0

Si ha iniciado sesión como alguien que no tiene permiso para ver esa base de datos/tabla, probablemente obtendrá ese resultado. ¿Estás utilizando el mismo inicio de sesión en la línea de comandos que estás a través de mysqli?

+0

Estoy pensando que esta es la respuesta más cercana hasta ahora. He estado teniendo un comportamiento extraño cuando me conecto al servidor. Solo puedo conectarme exitosamente como un usuario (a través de php, usando el terminal, puedo iniciar sesión como cualquier) por cualquier razón. Ese usuario parece tener subvenciones completas en la base de datos y la tabla en cuestión, incluso realicé un GRANT TODOS LOS PRIVILEGIOS en la base de datos en cuestión, y sigo recibiendo el mismo error. Esto es muy extraño. –

0

Podría estar relacionado con tener tablas InnoDB y MyISAM juntas. Si copia los archivos de la base de datos, MyISAM estará bien y el InnoDB se mostrará pero no funcionará.

+0

Esto es todo MyISAM, pero eso es un buen pensamiento –

44

Esto me pasó a mí y después de un tiempo encontré la respuesta en un artículo de blog, y quería ponerlo aquí también.

Si copia el directorio de datos de MySQL /var/lib/mysql-/path/to/new/dir, pero sólo copiar las carpetas de base de datos (es decir mysql, wpdb, ecommerce, etc) y usted tiene tablas InnoDB, las tablas InnoDB se mostrarán en 'Mostrar las tablas' pero las consultas en ellos (select y describe) fallarán, con el error Mysql error: table db.tableName doesn't exist. Verá el archivo .frm en el directorio db y se preguntará por qué.

Para tablas InnoDB, es importante copiar los archivos ib*, que en mi caso eran ibdata1, ib_logfile0 y ib_logfile1. Una vez que hice la transferencia asegurándome de copiarlos, todo funcionó como se esperaba.

Si su archivo my.cnf contiene "innodb_file_per_table", el archivo .ibd estará presente en el directorio db pero aún necesita los archivos ib *.

+3

Debo decir la respuesta que funcionó para mi situación, con suerte la tuya también :) – Isaac

+0

Esto funcionó para mí, ¡es útil saberlo! – DavidC799

+0

¡Muchas gracias! Acabas de salvar mi escondite. Esto funcionó muy bien. – user965879

4

Usar el mysqlcheck estaría en orden en este caso, por lo que puede descartar los problemas de cordura de la tabla & repararlos si es necesario.

0

Lo he visto en un sistema centos 6.4 con mysql 5.1 y un sistema de archivos xfs.

Las tablas muestran con 'mostrar tablas', pero una selección o descripción falla con el mensaje de tabla no existente como usted describió. Los archivos están donde espero que estén.

El sistema funcionó bien durante meses, luego de reiniciarse el servicio mysqld después de cambiar /etc/my.cnf para establecer table_cache en 512 en lugar de 256, se fue hacia los lados.

Según arcconf, el controlador de banda cree que todo está bien. xfs_check no encuentra nada. la lista de eventos del sistema de IPMI es clara. dmesg muestra algunas quejas de iptables sobre el seguimiento de la conexión y la caída de paquetes, por lo que es posible que hayamos descargado DOS, pero dado que no hay nada realmente abierto en el servidor, ¿no veo cómo podría afectar la integridad de los datos de mysql?

Terminé promocionando el esclavo para dominar y volver a cargar el sistema, y ​​ahora me pregunto qué pudo haber causado el error, y si la elección de xfs en centos 6.4 sigue siendo una elección estable, o si el culpable era mysql 5.1 .

Ah sí, y nunca cambian un sistema en funcionamiento :)

0

Mac OS X? DETENGA, no vuelva a copiar nada aún ...

Tuve este problema un par de veces en Mavericks. MySQL ya no está incluido, pero mi instalación es esencialmente la misma que esperaría encontrar en Snow Leopard, creo, en lugar de MAMP o algo así.

Después de migrar de una computadora a otra tuve este problema. Fue el resultado del panel de control de MySQL al iniciar mysqld, en lugar de iniciarlo en la línea de comandos. (Al migrar, este panel de control algo obsoleto olvida que usted le indicó NO iniciar al arrancar).

Observe los procesos (arriba o monitor de actividad), en mi sistema: si el propietario es root, se inició por lanzamiento y no funciona correctamente; el proceso correcto tendrá _mysql como propietario.

¡A veces, tengo ambos procesos funcionando uno al lado del otro!

Curiosamente, puede hacer todo, incluido el uso de mysql a través de la línea de comandos. Sin embargo, aunque se enumeran las tablas innodb, generan un error de no existir en la consulta.

Esto parece ser un problema de propiedad, que también puede aplicarse en otros sistemas.

0

Esto me sucedió cuando estaba tratando de seleccionar una tabla usando MAYÚSCULAS y el nombre de la tabla era minúscula.

Entonces, para resolver esta pregunta, puse "low_case_table_names = 1" en mi archivo .cnf.