parallel how mysql sql mysql-error-126

parallel - how to repair a table in mysql



MySQL, Error 126: archivo de clave incorrecto para la tabla (5)

Leí la siguiente pregunta que tiene relevancia, pero las respuestas no me satisficieron: MySQL: # 126 - Archivo de clave incorrecto para la tabla

El problema

Al ejecutar una consulta me sale este error

ERROR 126 (HY000): Archivo de clave incorrecto para la tabla

La pregunta

Cuando trato de encontrar el problema, no puedo encontrar uno, así que no sé cómo solucionarlo con el comando de reparación. ¿Hay alguna indicación de cómo puedo encontrar el problema que causa este problema de alguna otra manera que ya lo he intentado?

La consulta

mysql> SELECT -> Process.processId, -> Domain.id AS domainId, -> Domain.host, -> Process.started, -> COUNT(DISTINCT Joppli.id) AS countedObjects, -> COUNT(DISTINCT Page.id) AS countedPages, -> COUNT(DISTINCT Rule.id) AS countedRules -> FROM Domain -> JOIN CustomScrapingRule -> AS Rule -> ON Rule.Domain_id = Domain.id -> LEFT JOIN StructuredData_Joppli -> AS Joppli -> ON Joppli.CustomScrapingRule_id = Rule.id -> LEFT JOIN Domain_Page -> AS Page -> ON Page.Domain_id = Domain.id -> LEFT JOIN Domain_Process -> AS Process -> ON Process.Domain_id = Domain.id -> WHERE Rule.CustomScrapingRule_id IS NULL -> GROUP BY Domain.id -> ORDER BY Domain.host; ERROR 126 (HY000): Incorrect key file for table ''/tmp/#sql_2b5_4.MYI''; try to repair it

mysqlcheck

root@scraper:~# mysqlcheck -p scraper Enter password: scraper.CustomScrapingRule OK scraper.Domain OK scraper.Domain_Page OK scraper.Domain_Page_Rank OK scraper.Domain_Process OK scraper.Log OK scraper.StructuredData_Joppli OK scraper.StructuredData_Joppli_Product OK

filas contadas

mysql> select count(*) from CustomScrapingRule; +----------+ | count(*) | +----------+ | 26 | +----------+ 1 row in set (0.04 sec) mysql> select count(*) from Domain; +----------+ | count(*) | +----------+ | 2 | +----------+ 1 row in set (0.01 sec) mysql> select count(*) from Domain_Page; +----------+ | count(*) | +----------+ | 134288 | +----------+ 1 row in set (0.17 sec) mysql> select count(*) from Domain_Page_Rank; +----------+ | count(*) | +----------+ | 4671111 | +----------+ 1 row in set (11.69 sec) mysql> select count(*) from Domain_Process; +----------+ | count(*) | +----------+ | 2 | +----------+ 1 row in set (0.02 sec) mysql> select count(*) from Log; +----------+ | count(*) | +----------+ | 41 | +----------+ 1 row in set (0.00 sec) mysql> select count(*) from StructuredData_Joppli; +----------+ | count(*) | +----------+ | 11433 | +----------+ 1 row in set (0.16 sec) mysql> select count(*) from StructuredData_Joppli_Product; +----------+ | count(*) | +----------+ | 130784 | +----------+ 1 row in set (0.20 sec)

Actualizar

Uso del disco

root@scraper:/tmp# df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 20G 4.7G 15G 26% / none 4.0K 0 4.0K 0% /sys/fs/cgroup udev 237M 4.0K 237M 1% /dev tmpfs 49M 188K 49M 1% /run none 5.0M 0 5.0M 0% /run/lock none 245M 0 245M 0% /run/shm none 100M 0 100M 0% /run/user


Dividir una consulta compleja en varias puede ser más rápido sin necesidad de aumentar el tamaño de la tabla temporal


En mi caso, simplemente borré los archivos temporales de la ubicación temporal:

mi.ini

tmpdir = "D: / xampp / tmp"

Y funcionó para mí.


Parece que su consulta está devolviendo un gran conjunto de resultados intermedios que requieren la creación de una tabla temporal y que la ubicación configurada para las tablas de disco temporal mysql (/ tmp) no es lo suficientemente grande para la tabla temporal resultante.

Puedes intentar aumentar el tamaño de la partición tmpfs remontándola:

mount -t tmpfs -o remount,size=1G tmpfs /tmp

Puede hacer que este cambio sea permanente editando / etc / fstab

Si no puede hacer esto, puede intentar cambiar la ubicación de las tablas temporales del disco editando la entrada "tmpdir" en su archivo my.cnf (o agregarla si aún no está allí). Recuerde que el directorio que elija debe ser escribible por el usuario mysql

También puede intentar evitar la creación de una tabla temporal en disco aumentando los valores de las opciones de configuración de mysql:

tmp_table_size max_heap_table_size

a valores mayores. Tendrá que aumentar los dos parámetros anteriores

Ejemplo:

set global tmp_table_size = 1G; set global max_heap_table_size = 1G;


Si su montaje /tmp en un sistema de archivos linux se monta como un desbordamiento, a menudo tiene un tamaño de 1 MB, es decir,

$ df -h Filesystem Size Used Avail Use% Mounted on udev 7.9G 12K 7.9G 1% /dev tmpfs 1.6G 348K 1.6G 1% /run /dev/xvda1 493G 6.9G 466G 2% / none 4.0K 0 4.0K 0% /sys/fs/cgroup none 5.0M 0 5.0M 0% /run/lock none 7.9G 0 7.9G 0% /run/shm none 100M 0 100M 0% /run/user overflow 1.0M 4.0K 1020K 1% /tmp <------

esto probablemente se deba a que no especificó /tmp como su propia partición y su sistema de archivos raíz se llenó y /tmp se volvió a montar como una alternativa.

Me encontré con este problema después de quedarme sin espacio en un volumen EC2. Una vez que redimensioné el volumen, me encontré con la partición de desbordamiento /tmp llenaba mientras ejecutaba una vista complicada.

Para solucionar este problema después de haber borrado el espacio / redimensionado, simplemente desmonte el respaldo y debería volver a montar en su punto original (generalmente su partición raíz):

sudo umount -l /tmp

Nota: -Lo desmontará perezosamente el disco.


Solo necesitas reparar tu tabla que usas en la consulta de búsqueda. este problema generalmente ocurre en la consulta de búsqueda.

vaya a " table_name " -> operación -> efecto de reparación (solo un clic) puede tardar un poco en aplicarse