php - solucion - mysql error 1812

MySQL Table no existe error, pero existe (10)

¿Mac OS X? PARE, no vuelva a copiar nada todavía ...

Tuve este problema un par de veces en Mavericks. MySQL ya no está incluido, pero mi instalación es esencialmente la misma que la 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 de que el panel de control de MySQL haya iniciado mysqld, en lugar de que lo inicie en la línea de comandos. (Al migrar, este panel de control algo obsoleto olvida que le dijo que NO se iniciara en el arranque).

Mire los procesos (superior o monitor de actividad) en mi sistema: si el propietario es root, se inició con el inicio y no funciona correctamente; El proceso correcto tendrá _mysql como propietario.

A veces, tengo ambos procesos corriendo al lado!

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

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

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

Utilizo el mismo código en 5 servidores, solo uno que alquilé recientemente muestra este error, por lo que sospecho que puede ser una configuración o un error de instalación de algún tipo. Puedo ejecutar mi sentencia sql desde la línea de comando muy bien. Obviamente, también puedo ver la tabla desde la línea de comandos. No obtengo ningún error de conexión cuando establezco una conexión (estoy usando mysqli, por cierto).

Cualquier ayuda sería apreciada.

consulta exacta:

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

¿Podría ser que su único servidor es una caja de Linux? Mysql distingue entre mayúsculas y minúsculas en linux pero insensible en windows.

Básicamente, creo que el problema que estaba experimentando se debía a diferentes longitudes de hash de contraseñas. En mi caso, obtuve un nuevo servidor, realicé un volcado de MySQL completo en el que también se transfirieron las contraseñas y la información del usuario. El nuevo servidor ya se había inicializado con un usuario raíz que tenía un hash de 16 caracteres de longitud, pero mi servidor anterior estaba usando las nuevas longitudes de hash de 32 caracteres.

Tuve que ir a my.conf establecer la configuración de contraseñas antiguas a 0 (de lo contrario, cada vez que intentaba actualizar la base de datos, la nueva actualización tenía 16 caracteres de longitud). Luego actualicé todas las contraseñas para que sean iguales mediante el comando UPDATE mysql.user SET password=PASSWORD(''password here''); , luego me sonrojé 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 que confirmé que estaba funcionando.

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

El uso de mysqlcheck estaría en orden en este caso, por lo que puede descartar los problemas de higiene de la tabla y repararlos si es necesario.

Esto me acaba de pasar y, después de un tiempo, encontré la respuesta en un artículo del blog y también quería ponerla aquí.

Si copia el directorio de datos MySQL de /var/lib/mysql a /path/to/new/dir , pero solo copia las carpetas de la base de datos (es decir, mysql , wpdb , ecommerce , etc.) Y sí tiene tablas innodb, sus tablas innodb aparecerá en ''mostrar tablas'' pero las consultas en ellas ( 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 las tablas de innodb, es importante copiar sobre los archivos ib* , que en mi caso fueron ibdata1 , ib_logfile0 e 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_table", el archivo .ibd estará presente en el directorio db pero aún necesita los archivos ib *.

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

Entonces, para resolver esta pregunta, puse "lower_case_table_names = 1" en el archivo my.cnf.

He visto esto en un sistema centos 6.4 con mysql 5.1 y un sistema de archivos xfs.

Las tablas se muestran con ''mostrar tablas'' pero una selección o descripción falla con la tabla que no existe un mensaje como lo describió. Los archivos son donde espero que estén.

El sistema funcionó bien durante meses, luego, después de un servicio mysqld se reinicia después de cambiar /etc/my.cnf para establecer table_cache en 512 en lugar de 256, se fue de lado.

Según arcconf, el controlador de raid piensa que todo está bien. xfs_check no encuentra nada. La lista de eventos del sistema de IPMI está clara. dmesg muestra algunas quejas de iptables sobre el seguimiento de la conexión y la eliminación de paquetes, por lo que es posible que hayamos estado en DOS, pero como no hay nada realmente ejecutándose en el servidor, no veo cómo podría afectar la integridad de los datos de mysql.

Terminé promoviendo el esclavo para dominar y recargar 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 opción estable, o si el culpable fue mysql 5.1.

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

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

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

Tuve este tipo de comportamiento una vez. Más tarde descubrí que el controlador JDBC que usé 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 estaba usando las letras mixtas correctas.