español - mysql error codes

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

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

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

Obtuve el siguiente error de una consulta de MySQL.

#126 - Incorrect key file for table

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

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

EDITAR

También vale la pena señalar que esto puede ser causado por un ramdisk completo cuando se hacen cosas como alterar una tabla grande si 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.

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

KEY es normalmente un sinónimo de INDEX . El atributo clave PRIMARY KEY también se puede especificar como solo KEY cuando se proporciona 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 deberse a dos cosas:

Problemas de disco en el servidor MySQL
Teclas / claves corruptas

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 aumentar el tamaño de tmp o reducir las consultas! ;)

A veces, tmp es lo suficientemente grande pero aún así se llena, tendrás que hacer 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 la tabla REPARACIÓN . En general, es un proceso largo que podría fallar.

Mira el mensaje de error completo que obtienes:

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

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

si es algo como /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 debe repararla.

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

Error # 126 generalmente ocurre cuando tienes una tabla corrupta. 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

Intenta usar el límite en tu 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 :)

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.

Mi problema vino de una mala consulta. 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.

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

Necesitas:

detener el servicio MySQL:
Abre mysql / data
Elimine tanto ib_logfile0 como ib_logfile1.
Reiniciar el servicio

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

Mostrar 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 umount /tmp y /var/tmp :

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

A continuación, elimine el archivo de la partición corrupta:

rm -fv /usr/tmpDSK

Luego crea una nueva y agradable:

/scripts/securetmp

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

Solucioné este problema con:

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

Mayo ayuda

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

Ve a /etc/my.cnf y comenta los tmpfs

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

ft_min_word_len = 2 este error cuando configuro ft_min_word_len = 2 en my.cnf , lo que reduce la longitud de palabra mínima en un índice de texto completo a 2, del valor predeterminado de 4.

Reparar la mesa resolvió el problema.

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

Entonces, aparece el 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 mí

repair table myschema.mytable;