parallel how extended mysql sql mysql-error-126

how - Archivo de clave incorrecta de MySQL para la tabla tmp al realizar varias combinaciones



parallel repair mysql (11)

No vengo aquí a menudo por ayuda, pero estoy bastante frustrado por esto y espero que alguien lo haya encontrado antes.

Cada vez que intento buscar registros de una tabla usando más de una combinación, obtengo este error:

#126 - Incorrect key file for table ''/tmp/#sql_64d_0.MYI''; try to repair it

Entonces esta consulta producirá el error:

SELECT * FROM `core_username` INNER JOIN `core_person` ON (`core_username`.`person_id` = `core_person`.`id`) INNER JOIN `core_site` ON (`core_username`.`site_id` = `core_site`.`id`) ORDER BY `core_username`.`name` ASC LIMIT 1

Pero este no:

SELECT * FROM `core_username` INNER JOIN `core_person` ON (`core_username`.`person_id` = `core_person`.`id`) ORDER BY `core_username`.`name` ASC LIMIT 1

Y tampoco esta:

SELECT * FROM `core_username` INNER JOIN `core_site` ON (`core_username`.`site_id` = `core_site`.`id`) ORDER BY `core_username`.`name` ASC LIMIT 1

¿Qué podría estar causando esto? Realmente no sé cómo reparar una tabla tmp, pero realmente no creo que ese sea el problema ya que es una nueva tabla tmp cada vez. La tabla de nombre de usuario es bastante grande (233,718 registros en este momento) pero dudo que tenga algo que ver con eso.

Cualquier ayuda sería muy apreciada.

ACTUALIZACIÓN : después de algunas pruebas adicionales, parece que el error solo ocurre cuando intento ordenar los resultados. Es decir, esta consulta me dará lo que espero:

SELECT * FROM `core_username` INNER JOIN `core_person` ON (`core_username`.`person_id` = `core_person`.`id`) INNER JOIN `core_site` ON (`core_username`.`site_id` = `core_site`.`id`) LIMIT 1

Pero si agrego el:

ORDER BY `core_username`.`name` ASC

El error se desencadena Esto solo ocurre en el servidor web específico que estoy usando actualmente. Si descargo la base de datos y pruebo lo mismo en mi servidor local y en otros servidores, funciona bien. La versión de MySQL es 5.0.77.

Sabiendo esto, estoy bastante seguro de que lo que está sucediendo es que la tabla tmp que se está creando es demasiado grande y MySQL se bloquea como se describe en esta publicación del blog . Todavía no estoy seguro de cuál sería la solución, aunque ...

A veces, cuando este error ocurre con las tablas temporales:

#126 - Incorrect key file for table ''/tmp/#sql_64d_0.MYI''; try to repair it

Puede ser porque la carpeta /tmp está quedando sin espacio. En algunas instalaciones de Linux, /tmp está en su propia partición y no tiene mucho espacio, las grandes consultas de MySQL lo llenarán.

Puede usar df -h para comprobar si /tmp está en su propia partición y cuánto espacio le está asignado.

Si está en su propia partición y le falta espacio, puede:

(a) modifique / tmp para que su parición tenga más espacio (reasignando o moviéndolo a la partición principal, por ejemplo, vea aquí )
(b) cambiando la configuración de MySql para que use una carpeta temporal diferente en una partición diferente, por ejemplo, /var/tmp

Compruebe el espacio disponible de su tmpdir de MySQL (/ tmp en su caso) mientras ejecuta las consultas, ya que puede comer cientos de MB al trabajar con tablas grandes. Algo como esto funcionó para mí:

$ while true; do df -h /tmp; sleep .5; done

El uso de la palabra clave EXPLAIN puede ayudar a encontrar la mejor forma de optimizar esta consulta. Básicamente, lo que debe hacer es obtener el conjunto de resultados lo más pequeño posible lo más rápido posible. Si tiene un conjunto de resultados de cada fila en core_username hasta el final, cuando lo ordena corre el riesgo de ... esto.

Si puede hacer el pedido en core_username solo sin ningún problema, es posible que desee obtener la fila min () como una subconsulta.

En Unix, MySQL usa el valor de la variable de entorno TMPDIR como nombre de ruta del directorio en el que almacenar los archivos temporales. Si TMPDIR no está configurado, MySQL usa el sistema predeterminado, que generalmente es / tmp, / var / tmp, o / usr / tmp.

En Windows, Netware y OS2, MySQL verifica en orden los valores de las variables de entorno TMPDIR, TEMP y TMP. Para el primero que se estableció, MySQL lo usa y no verifica los que quedan. Si no se configura ninguno de TMPDIR, TEMP o TMP, MySQL usa el sistema predeterminado de Windows, que generalmente es C: / windows / temp.

Si el sistema de archivos que contiene su directorio de archivos temporales es demasiado pequeño, puede usar la opción --tmpdir para mysqld para especificar un directorio en un sistema de archivos donde tenga suficiente espacio .

En MySQL 5.0, la opción --tmpdir se puede establecer en una lista de varias rutas que se utilizan en forma de round-robin. Las rutas deben estar separadas por caracteres de dos puntos (":") en Unix y caracteres de punto y coma (";") en Windows, NetWare y OS / 2.

Experimento el mismo problema.

Aquí está mi solución: 1. No use "seleccionar *". Solo seleccione el campo que necesita. 2. Divida la consulta. Si el campo que selecciona es demasiado, dividirlo en alguna consulta puede ser un resultado. Puede "array_merge ()" el ​​resultado más adelante si desea que la variable que contiene el resultado no se modifique.

En mi caso, dividí la consulta en 5 consultas, luego la matriz se fusionó usando PHP.

El problema son las mentiras en el servidor mysql. Es solo una cosa que el desarrollador de aplicaciones (como yo) no tiene un privilegio.

Puede encontrar que ejecutar "ANALYZE TABLE" ayuda.

Tuvimos este problema de repente aparece en una tabla grande (~ 100M filas) y MySQL intentó usar / tmp para escribir una tabla temporal de más de 1GB, que falló como / tmp se limitó a ~ 600M.

Resultó que las estadísticas para la tabla InnoDB eran bastante obsoletas. Después de ejecutar "ANALYZE TABLE ...", las estadísticas se actualizaron y se solucionó el problema. Con las estadísticas más precisas, MySQL pudo optimizar la consulta correctamente y ya no se necesitaba el archivo tmp grande.

Ahora ejecutamos "mysqlcheck -A" periódicamente para mantener actualizadas todas las estadísticas de la tabla.

Tuve este problema con una consulta en una tabla que tenía 500K + registros. Me estaba dando el mismo tipo exacto de error, apuntando a un archivo .MYI en el directorio / tmp que rara vez estaba allí al verificar. Ya había aumentado los tamaños de archivo de almacenamiento dinámico y temporal en el archivo /etc/my.cnf.

El problema con la consulta era que efectivamente contenía una cláusula ORDER al final, omitiendo que la consulta funcionara sin error. También tenía un LÍMITE. Estaba tratando de ver los 5 registros más recientes en la tabla. Con la cláusula ORDER incluida, se bloqueó y dio el error.

Lo que sucedía era que el mysqld estaba creando una tabla temporal interna con TODOS los registros de la tabla gigante para aplicar el PEDIDO.

La forma en que solucioné esto es aplicando una condición WHERE adicional, limitando los registros de la tabla gigante a un conjunto más pequeño. Convenientemente tenía un campo de fecha y hora para filtrar.

Espero que ayude a alguien.

Tuve un problema similar. En mi propio caso, el problema ocurrió debido a un propietario / permiso incorrecto. Solo tuve que cambiar el propietario de mi directorio de datos a usuario de mysql y esto resolvió el problema.

ejecuta esto

REPAIR TABLE `core_username`,`core_site`,`core_person`;

o haz esto:

select * from ( SELECT * FROM `core_username` INNER JOIN `core_person` ON (`core_username`.`person_id` = `core_person`.`id`) INNER JOIN `core_site` ON (`core_username`.`site_id` = `core_site`.`id`) LIMIT 1) ORDER BY `name` ASC

las claves de índice para una de las 3 tablas pueden estar mal, intente ejecutar un comando de reparación en las 3 tablas.