MySQL: #126: 테이블에 대한 잘못된 키 파일

MySQL: #126: 테이블에 대한 잘못된 키 파일

MySQL 쿼리에서 다음과 같은 오류가 발생했습니다.

#126 - Incorrect key file for table

이 표의 키도 선언하지 않았지만 인덱스는 가지고 있습니다.뭐가 문제인지 아는 사람 있어요?

매번 이런 일이 일어날 때마다, 제 경험상 디스크는 완전히 꽉 찼습니다.

편집

또한 RAMDisk가 구성되어 있는 경우 큰 테이블을 변경하는 등의 작업을 수행할 때 RAMD가 가득 차서 발생할 수 있습니다.ramdisk 행을 일시적으로 주석을 달아 크기를 늘릴 수 없는 경우 이러한 작업을 허용할 수 있습니다.

우선 MySQL에서 키와 인덱스는 동의어라는 것을 알아야 합니다.CREATE TABLE Syntax에 대한 문서를 참조하면 다음을 볼 수 있습니다.

KEY 는 보통 와 동의어입니다.키 속성은 열 정의에 지정된 대로 지정할 수도 있습니다.이는 다른 데이터베이스 시스템과의 호환성을 위해 구현되었습니다.

---

에러의 종류는, 다음의 2개의 원인으로 생각할 수 있습니다.

• MySQL 서버의 디스크 문제
• 키/테이블 파손

첫 번째 경우 쿼리에 제한을 추가하면 문제가 일시적으로 해결될 수 있습니다.그게 당신에게 충분하다면, 당신은 아마도tmp수행하려는 쿼리 크기에 비해 너무 작은 폴더입니다. 수 .tmp더 크게 또는 더 작게 질문할 수 있습니다.;)

,,,,,tmp크기는 충분하지만 가득 차기 때문에 이러한 상황에서는 수동으로 청소해야 합니다.

두 번째 경우 MySQL의 데이터에 실제 문제가 있습니다.데이터를 쉽게 재삽입할 수 있다면 테이블을 드롭/재작성하고 데이터를 재삽입하는 것이 좋습니다.할 수 없는 경우는, 수복 테이블로 테이블을 수복해 주세요.그것은 실패할 가능성이 높은 일반적으로 긴 과정이다.

---

에러 메시지 전체를 확인합니다.

'FILEPATH' 테이블의 키 파일이 잘못되었습니다.MYI'; 수복을 시도하다

메시지에는 복구를 시도할 수 있다고 나와 있습니다.또, 실제의 FILE PATH 를 참조하면, 다음의 정보를 얻을 수 있습니다.

• 같은 /tmp/#sql_ab34_23f즉, 쿼리 크기 때문에 MySQL에서 임시 테이블을 생성해야 합니다.이 파일은 /tmp에 저장되며 /tmp에 해당 임시 테이블을 위한 충분한 공간이 없습니다.

• 대신 실제 테이블의 이름이 포함된 경우 이 테이블이 손상되었을 가능성이 높으므로 복구해야 합니다.

---

문제가 /tmp 사이즈에 있다고 판단되는 경우는, 이 수정에 관한 같은 질문에 대한 회답(MySQL, Error 126: Incorrect key file for table)을 읽어 주세요.

다음의 순서에 따라서, tmp 디렉토리를 재작성해, 문제를 해결할 수 있는 방법은 다음과 같습니다.

모든 파일 시스템과 해당 디스크 사용량을 사람이 읽을 수 있는 형태로 표시합니다.

df -h

파일이 열려 있는 프로세스를 찾습니다./tmp

sudo lsof /tmp/**/*

그럼 umount/tmp그리고./var/tmp:

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

그런 다음 손상된 파티션 파일을 제거합니다.

rm -fv /usr/tmpDSK

그런 다음 멋진 새 것을 만듭니다.

/scripts/securetmp

securetmp Perl 스크립트를 편집하면 tmp 디렉토리의 크기를 직접 설정할 수 있지만 스크립트를 실행하는 것만으로 서버상의 tmp 디렉토리의 크기가 약 450MB에서 4.0으로 늘어납니다.GB

일반적으로 테이블이 파손되었을 때 오류 #126이 발생합니다.이 문제를 해결하는 가장 좋은 방법은 수리를 하는 것입니다.이 문서는 도움이 될 수 있습니다.

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

설정했을 때 이 에러가 발생했습니다.ft_min_word_len = 2에my.cnf전체 텍스트 인덱스의 최소 단어 길이를 기본 4에서 2로 낮춥니다.

테이블을 수리하면 문제가 해결되었다.

이것이 오래된 주제인 것은 알지만, 언급된 해결책 중 어느 것도 나에게 효과가 없었다.다른 방법으로도 효과가 있었습니다.

다음 사항이 필요합니다.

1. MySQL 서비스를 중지합니다.
2. mysql\data 열기
3. ib_logfile0과 ib_logfile1을 모두 삭제합니다.
4. 서비스를 재시작합니다.

쿼리에서 제한을 사용해 보십시오.@Monsters X가 말한 풀디스크 때문입니다.

저 또한 이 문제에 직면했고 수천 개의 레코드가 있었기 때문에 질의에 제한을 두고 해결했습니다.정상적으로 동작하고 있습니다. :)

repair table myschema.mytable;

이 문제를 해결했습니다.

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

메이 헬프다

• 참조: MySQL: ALTER IGNORE TABLE이 "Integrity 제약 조건 위반"을 발생시킵니다.

이제 다른 대답으로 해결됐네요.동일한 쿼리에서 열과 인덱스의 이름을 바꾸면 오류가 발생한 것으로 나타났습니다.

동작하지 않음:

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

작업 (2개의 스테이트먼트):

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

이것은 MariaDB 10.0.20에 관한 것입니다.MySQL 5.5.48에서 동일한 쿼리에 오류가 없습니다.

에 가다/etc/mysql/my.cnf코멘트 아웃tmpfs

#tmpdir=/var/tmpfs

이것으로 문제가 해결됩니다.

다른 답변에서 제시된 명령어를 실행했는데 디렉토리가 작을 때 비어있었기 때문에 공간이 문제가 되지 않았습니다.

/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

쿼리에 관련된 각 테이블에 대해 복구 명령을 실행해 보십시오.

MySQL 관리자를 사용하여 카탈로그 -> 카탈로그 선택 -> 테이블 선택 -> 유지보수 버튼 -> 복구 -> FRM 사용으로 이동합니다.

제 문제는 잘못된 질의에서 비롯되었습니다.SELECT에서 참조되지 않은 FROM의 테이블을 참조했습니다.

예:

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

, users u★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★그것을 제거하면 문제가 해결된다.

참고로 이것은 CodeIgniter 개발 환경에서의 것입니다.

ft_min_word_len(풀텍스트 최소 단어 길이)을 줄인 후 테이블에 쓸 때 이 메시지가 나타납니다.이 문제를 해결하려면 테이블을 복구하여 인덱스를 다시 생성하십시오.

"#1034: 테이블 'test'에 대한 잘못된 키 파일입니다. 복구해 보십시오."를 검색하러 왔습니다.

Mysql 8.0.21을 사용하여 인덱스된 Enum(다른 필드와 동일할 수 있음)에 charset을 추가함으로써 이 문제가 발생합니다.

CREATE TABLE `test` (
`enumVal` ENUM( 'val1' ) NOT NULL
) ENGINE = MYISAM;
ALTER TABLE `test` ADD INDEX ( `enumVal` );

ALTER TABLE  `test` CHANGE  `enumVal`  `enumVal` ENUM(  'val1') CHARACTER SET utf8 COLLATE utf8_bin NOT NULL;

솔루션 사용법은 변경 전에 인덱스를 드롭하는 것입니다.

ALTER TABLE `test` ADD INDEX ( `enumVal` );

mysqlcheck -r -f  -uroot -p   --use_frm db_name

통상은 효과가 있다

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

다음으로 get 에러가 존재합니다.

 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> repair table f_scraper_banner_details;

이건 내게 효과가 있었다.

언급URL : https://stackoverflow.com/questions/2011050/mysql-126-incorrect-key-file-for-table