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

Recibí el siguiente error de una consulta MySQL.

#126 - Incorrect key file for table

Ni siquiera he declarado una clave para esta tabla, pero tengo índices. ¿Alguien sabe cuál podría ser el problema?

Cada vez que esto ha sucedido, ha sido un disco lleno en mi experiencia.

EDITAR

También vale la pena señalar que esto puede ser causado por un ramdisk completo al hacer cosas como alterar una tabla grande si tiene un ramdisk configurado. Puede comentar temporalmente la línea ramdisk para permitir tales operaciones si no puede aumentar su tamaño.

En primer lugar, debe saber que las claves y los índices son sinónimos en MySQL. Si observa la documentación sobre la sintaxis CREATE TABLE , puede leer:

KEYes normalmente un sinónimo de INDEX. El atributo de clave PRIMARY KEYtambién se puede especificar KEYcuando se proporciona en una definición de columna. Esto se implementó por compatibilidad con otros sistemas de bases de datos.

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

• Problemas de disco en el servidor MySQL
• Teclas / tablas dañadas

En el primer caso, verá que agregar un límite a su consulta podría resolver el problema temporalmente. Si eso es suficiente para usted, probablemente tenga una tmpcarpeta que sea demasiado pequeña para el tamaño de las consultas que está tratando de hacer. A continuación, puede decidir hacer tmpmás grande o hacer sus consultas más pequeñas. ;)

A veces, tmpes lo suficientemente grande pero aún se llena, necesitará hacer una limpieza manual en estas situaciones.

En el segundo caso, existen problemas reales con los datos de MySQL. Si puede volver a insertar los datos fácilmente, le aconsejo que simplemente suelte / vuelva a crear la tabla y vuelva a insertar los datos. Si no puede, intente reparar la mesa en su lugar con la mesa REPAIR . Es un proceso generalmente largo que bien podría fallar.

Mire el mensaje de error completo que recibe:

Archivo de clave incorrecto para la tabla 'FILEPATH.MYI'; intenta repararlo

Menciona en el mensaje que puede intentar repararlo. Además, si observa el FILEPATH real que obtiene, puede encontrar más:

• si es algo así /tmp/#sql_ab34_23f, significa que MySQL necesita 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 que debería repararla.

Si identifica que su problema es con el tamaño de / tmp, simplemente lea esta respuesta a una pregunta similar para la solución: MySQL, Error 126: Archivo de clave incorrecto para la tabla .

Seguir estas instrucciones me permitió volver a crear mi directorio tmp y solucionar el problema:

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

df -h

Encuentre los procesos que tienen archivos abiertos en /tmp

sudo lsof /tmp/**/*

Luego desmonte /tmpy /var/tmp:

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

Luego elimine el archivo de partición corrupto:

rm -fv /usr/tmpDSK

Luego crea uno nuevo y agradable:

/scripts/securetmp

Tenga en cuenta que al editar el script de Securetmp Perl, usted mismo puede establecer manualmente el tamaño del directorio tmp, sin embargo, con solo ejecutar el script, el tamaño del directorio tmp en nuestro servidor aumentó de aproximadamente 450 MB a 4,0 GB.

El error # 126 generalmente ocurre cuando tiene una tabla corrupta. La mejor forma de solucionar este problema es realizar una reparación. Este artículo puede ayudar:

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

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

La reparación de la mesa solucionó el problema.

Intente utilizar el límite en su consulta. Es por el disco lleno como dijo @Monsters X.

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

Sé que este es un tema antiguo, pero ninguna de las soluciones mencionadas funcionó para mí. He hecho algo más que funcionó:

Necesitas:

1. detenga el servicio MySQL:
2. Abra mysql \ data
3. Elimine ib_logfile0 e ib_logfile1.
4. Reiniciar el servicio

repair table myschema.mytable;

Solucioné este problema con:

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

Puede ayudar

• Refs: MySQL: ALTER IGNORE TABLE da "Violación de restricción de integridad"

Ir a /etc/my.cnfy comentartmpfs

#tmpdir=/var/tmpfs

Esto soluciona el problema.

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

/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

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

Use 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.

Ahora, las otras respuestas me lo resolvieron. Resulta que cambiar el nombre de una columna y un índice en la misma consulta provocó el error.

No funciona:

-- 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);

Obras (2 declaraciones):

-- 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.

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

Entonces existe un 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> tabla de reparación f_scraper_banner_details;

Esto funcionó para mi

Mi problema provino de una mala consulta. Hice referencia a una tabla en FROM y 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 ues lo que me estaba causando el problema. Eliminar eso resolvió el problema.

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

Recibí este mensaje al escribir en una tabla después de reducir ft_min_word_len (longitud de palabra mínima de texto completo). Para solucionarlo, vuelva a crear el índice reparando la tabla.

mysqlcheck -r -f -uroot -p --use_frm nombre_bd

normalmente hará el truco