MySQL: # 126 - Archivo de clave incorrecta para la tabla

Question

Recibí el siguiente error de una consulta de MySQL.

#126 - Incorrect key file for table

que aun no han declarado una clave para esta tabla, pero tengo índices. ¿Alguien sabe cuál podría ser el problema?

Answer 1

El error # 126 generalmente se produce cuando tiene una tabla dañada. La mejor manera de resolver esto es realizar reparaciones. Este artículo podría ayudar:

http://dev.mysql.com/doc/refman/5.0/en/repair-table.html

Answer 2

cada vez que esto ha sucedido, que ha sido un disco completo en mi experiencia.

EDITAR

También vale la pena señalar que esto puede ser causado por un disco de memoria llena al hacer cosas como alterar una mesa grande si usted tiene un disco RAM configurado. Puede comentar temporalmente la línea de ramdisk para permitir tales operaciones si no puede aumentar el tamaño de la misma.

Answer 3

Intente ejecutar un comando de reparación para cada una de las tablas involucradas en la consulta.

Utilice el administrador de MySQL, vaya a Catálogo -> Seleccione su catálogo -> Seleccione una tabla -> Haga clic en el botón Mantenimiento -> Reparar -> Usar FRM.

Answer 4

Siguiendo estas instrucciones me permitió recrear mi directorio tmp y solucionar el problema:

Pantalla todos los sistemas de archivos y su uso del disco en forma legible por humanos:

df -h 

Encuentra los procesos que tienen archivos abiertos en /tmp

sudo lsof /tmp/**/* 

Entonces umount /tmp y /var/tmp:

umount -l /tmp 
umount -l /var/tmp 

continuación, quitar los archivos de la partición corrupta:

rm -fv /usr/tmpDSK 

continuación, crear un buen uno nuevo:

/scripts/securetmp 

Tenga en cuenta que al editar la secuencia de comandos securetmp Perl se puede ajustar manualmente el tamaño de el directorio tmp mismo, sin embargo, solo ejecutar el script aumentó el tamaño del directorio tmp en nuestro servidor de aproximadamente 450MB a 4.0GB.

Answer 5

Intente utilizar el límite en su consulta. Es debido al disco completo como lo dice @Monsters X.

También me he enfrentado a este problema y lo resolví por límite en la consulta, porque los miles de registros estaban allí. Ahora funciona bien :)

Answer 6

En primer lugar, debe saber que las claves y los índices son sinónimos en MySQL.Si nos fijamos en la documentación acerca de la CREATE TABLE Syntax, se puede leer:

KEY es normalmente sinónimo de INDEX. El atributo clave PRIMARY KEY también se puede especificar como KEY cuando se especifica en una definición de columna. Esto se implementó para compatibilidad con otros sistemas de bases de datos.

---

Ahora, el tipo de error que está recibiendo puede ser debido a dos cosas:

• problemas de disco en el servidor MySQL
• dañados llaves/mesas

En el primer caso, verá que agregar un límite a su consulta podría resolver el problema temporalmente. Si eso lo hace por usted, probablemente tenga una carpeta tmp que es demasiado pequeña para el tamaño de las consultas que está tratando de hacer. ¡Entonces puede decidir o hacer tmp más grande, o para hacer sus consultas más pequeñas! ;)

A veces, tmp es lo suficientemente grande pero todavía se llena, deberá realizar una limpieza manual en estas situaciones.

En el segundo caso, hay problemas reales con los datos de MySQL. Si puede volver a insertar los datos fácilmente, le aconsejaría simplemente dejar/volver a crear la tabla, y volver a insertar los datos. Si no puede, puede intentar reparar la mesa en su lugar con REPAIR table. En general, es un proceso largo que podría fallar.

---

Mira el mensaje de error completo se obtiene: archivo de clave

incorrecta para la tabla 'FILEPATH.MYI'; intente repararlo

Menciona en el mensaje que usted puede intentar repararlo. Además, si nos fijamos en la FILEPATH real que se obtiene, se puede encontrar más información:

• si se trata de algo así como /tmp/#sql_ab34_23f que significa que MySQL necesita para crear una tabla temporal, debido al tamaño de la consulta. Lo almacena en/tmp y no hay suficiente espacio en su/tmp para esa tabla temporal.

• si contiene el nombre de una tabla real en su lugar, significa que es muy probable que esta tabla esté dañada y debe repararla.

---

Si se identifica que su problema está relacionado con el tamaño de/tmp, acabo de leer esta respuesta a una pregunta similar para la revisión: MySQL, Error 126: Incorrect key file for table.

Answer 7

Tengo este error cuando me puse en ft_min_word_len = 2my.cnf, lo que disminuye la longitud mínima palabra en un índice de texto completo a los 2, el valor predeterminado de 4.

Reparación de la mesa fija el problema.

Answer 8

Sé que este es un tema antiguo, pero ninguna de las soluciones mencionadas funcionó para mí. Yo he hecho otra cosa que funcionó:

es necesario:

1. detenga el servicio MySQL:
2. abierto mysql \ data
3. eliminar tanto ib_logfile0 y ib_logfile1.
4. Reiniciar el servicio

Answer 9

repair table myschema.mytable; 

Answer 10

He arreglado este asunto con:

ALTER TABLE table ENGINE MyISAM; 
ALTER IGNORE TABLE table ADD UNIQUE INDEX dupidx (field); 
ALTER TABLE table ENGINE InnoDB; 

mayo de ayuda

• Refs: MySQL: ALTER IGNORE TABLE gives "Integrity constraint violation"

Answer 11

Ir a /etc/my.cnf y comente tmpfs

#tmpdir=/var/tmpfs 

Esto soluciona el problema.

Ejecuté el comando sugerido en otra respuesta y mientras el directorio es pequeño, estaba vacío, por lo que el espacio no era el problema.

/var/tmp$ df -h 
Filesystem   Size Used Avail Use% Mounted on 
/dev/vzfs    60G 51G 9.5G 85%/
none     1.5G 4.0K 1.5G 1% /dev 
tmpfs     200M  0 200M 0% /var/tmpfs 
/var/tmpfs$ df -h 
Filesystem   Size Used Avail Use% Mounted on 
/dev/vzfs    60G 51G 9.5G 85%/
none     1.5G 4.0K 1.5G 1% /dev 
tmpfs     200M  0 200M 0% /var/tmpfs 

Answer 12

Ahora de las otras respuestas lo resolvió para mí. Resulta que cambiar el nombre de una columna y un índice en la misma consulta causó el error.

No trabaja:

-- rename column and rename index 
ALTER TABLE `client_types` 
    CHANGE `template_path` `path` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL, 
    DROP INDEX client_types_template_path_unique, 
    ADD UNIQUE INDEX `client_types_path_unique` (`path` ASC); 

Works (2) estados:

-- rename column 
ALTER TABLE `client_types` 
    CHANGE `template_path` `path` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL; 
-- rename index 
ALTER TABLE `client_types` 
    DROP INDEX client_types_template_path_unique, 
    ADD UNIQUE INDEX `client_types_path_unique` (`path` ASC); 

Esto fue en MariaDB 10.0.20. No hubo errores con la misma consulta en MySQL 5.5.48.

Answer 13

mysql> set global sql_slave_skip_counter=1; start slave; show slave status\G 

dieron entonces existe error:

Error 'Table './openx/f_scraper_banner_details' is marked as crashed and should be repaired' on query. Default database: 'openx'. Query: 'INSERT INTO f_scraper_banner_details(job_details_id, ad_id, client_id, zone_id, affiliateid, comments, pct_to_report, publisher_currency, sanity_check_enabled, status, error_code, report_date) VALUES (10274859, 321264, 0, 31926, 0, '', -1, 'USD', 1, 'FAILURE', 'INACTIVE_BANNER', '2016-06-28 04:00:00')' 

mysql> f_scraper_banner_details mesa de reparación;

Esto funcionó para mí

Answer 14

Mi problema provenía de una consulta mal. Hice referencia a una tabla en FROM no se hizo referencia en SELECT.

ejemplo:

SELECT t.*,s.ticket_status as `ticket_status` 
    FROM tickets_new t, ticket_status s, users u 

, users u es lo que estaba causando el problema para mí. Eliminar eso resolvió el problema.

Como referencia, esto fue en un entorno de desarrollo CodeIgniter.