MySQL5.6 CHECK TABLE 구문

13.7.2.2 CHECK TABLE 구문

CHECK TABLE tbl_name [, tbl_name] ... [option] ...

option = {
    FOR UPGRADE
  | QUICK
  | FAST
  | MEDIUM
  | EXTENDED
  | CHANGED
}

CHECK TABLE 은 하나 이상의 테이블을 오류가 있는지 확인합니다. CHECK TABLE 은 InnoDB , MyISAM , ARCHIVE 및 CSV 테이블에서 작동합니다. MyISAM 테이블의 경우, 키 통계 업데이트도 실행됩니다.

테이블을 확인하려면 그에 대한 어떤 권한이 필요합니다.

CHECK TABLE 은 또한보기를 체크하여 뷰 정의에서 참조되는 테이블이 존재하지 않게되는 등의 문제가 있는지 여부를 확인할 수 있습니다.

CHECK TABLE 은 파티션 된 테이블에 대해 지원되는 때문에 ALTER TABLE ... CHECK PARTITION 을 사용하여 하나 이상의 파티션을 확인할 수 있습니다. 자세한 내용은 섹션 13.1.7 "ALTER TABLE 구문」 및 섹션 19.3.4 "파티션 관리" 를 참조하십시오.

MySQL 5.6.11에서만이 문을 발행하기 전에 gtid_next 를 AUTOMATIC 으로 설정해야합니다. (Bug # 16062608, Bug # 16715809, Bug # 69045)

출력

CHECK TABLE 은 다음 컬럼을 포함하는 결과 집합을 반환합니다.

컬럼	값
`Table`	테이블 이름
`Op`	항상 `check`
`Msg_type`	`status` , `error` , `info` , `note` 또는 `warning`
`Msg_text`	정보 메시지

이 문은 체크 된 테이블마다 다수의 정보 행이 생성 될 가능성이 있습니다. 마지막 줄에는 status 의 Msg_type 값이 포함되어 Msg_text 은 일반적으로 OK 입니다. OK 또는 Table is already up to date 를 얻을 수없는 경우 일반적으로 그 테이블 복구를 수행해야합니다. 섹션 7.6 "MyISAM 테이블의 보수와 크래쉬 복구" 를 참조하십시오. Table is already up to date 는 그 테이블의 스토리지 엔진이 테이블의 체크는 필요 없다고 판단한 것을 나타냅니다.

버전 호환성 체크

FOR UPGRADE 옵션은 지정된 테이블이 현재 MySQL 버전과 호환 여부를 확인합니다. FOR UPGRADE 를 지정하면 서버는 각 테이블을 체크하여 테이블을 만든 후 테이블 중 하나의 데이터 유형 또는 인덱스에서 호환되지 않는 변경이 발생하는지 여부를 판정합니다. 발생하지 않은 경우에는 체크가 성공합니다. 그렇지 않으면 비 호환성의 가능성이있는 경우, 서버는 그 테이블에 대해 철저한 검사를 실행합니다 (여기에는 어느 정도 시간이 걸릴 수 있습니다.) 철저한 검사가 성공하면 서버는 테이블의 .frm 파일을 현재 MySQL 버전 번호로 표시합니다. .frm 파일을 표시하면이 테이블에 동일한 버전의 서버가 이후 체크가 확실히 빨라집니다.

데이터 형 스토리지 포맷이 변경되었는지 또는 정렬 순서가 변경 되었기 때문에 호환성 문제가 발생할 수 있습니다. 우리의 목표는 그 변경을 피할 수 있지만 각 릴리스 간의 비 호환성보다 더 심각한 문제를 해결하기 위해 필요한 경우도 있습니다.

현재 FOR UPGRADE 는 다음의 비 호환성이 감지되고 있습니다.

InnoDB 와 MyISAM 테이블의 TEXT 컬럼의 마지막 영역의 인덱스 순서가 MySQL 4.1과 5.0 사이에서 변경되었습니다.
새로운 DECIMAL 데이터 유형의 저장 방법이 MySQL 5.0.3과 5.0.5 사이에서 변경되었습니다.
테이블이 현재 실행하고있는 것과 다른 버전의 MySQL 서버에서 생성 된 경우 FOR UPGRADE 는 그 테이블에 호환되지 않는 버전의 .frm 파일이 포함되어 있는지를 나타냅니다. 이 경우 CHECK TABLE 에 의해 반환 된 결과 집합에는 Msg_type 값이 error 에서 Msg_text 값이 Table upgrade required. Please do "REPAIR TABLE ` tbl_name `" to fix it! 인 행이 포함되어 있습니다.
문자 세트 또는 데이터 정렬에 대해 테이블 인덱스의 재 구축이 필요한 변경 될 수 있습니다. 이러한 변화와 그것이 FOR UPGRADE 의해 언제 검출되는지 자세한 내용은 섹션 2.11.3 "테이블 또는 인덱스 재구성이 필요한지 확인" 을 참조하십시오.
YEAR(2) 데이터 타입은 MySQL 5.6.6의 시점에서 비추천입니다. YEAR(2) 컬럼을 포함하는 테이블의 경우, CHECK TABLE 은 YEAR(2) 를 YEAR(4) 로 변환하는 REPAIR TABLE 이 권장됩니다.

데이터 일관성 검사

지정할 수있는 다른 검사 옵션을 다음 표에 나타냅니다. 이 옵션은 스토리지 엔진에 전달되지만, 거기서 사용되는 경우와되지 않는 경우가 있습니다.

유형	의미
`QUICK`	잘못된 링크를 체크하기위한 행의 스캔을하지 않습니다. `InnoDB` 와 `MyISAM` 테이블과 뷰에 적용됩니다.
`FAST`	제대로 닫히지 않은 테이블 만 검사합니다. `MyISAM` 테이블과 뷰에만 적용됩니다. `InnoDB` 는 무시됩니다.
`CHANGED`	마지막 검사 이후에 변경된하거나 제대로 닫히지 않은 테이블 만 체크합니다. `MyISAM` 테이블과 뷰에만 적용됩니다. `InnoDB` 는 무시됩니다.
`MEDIUM`	삭제 된 링크가 유효한지 검증하기 위해 로우를 스캔합니다. 또한 행의 키 체크섬도 계산하고 키의 계산 된 체크섬을 사용하여이를 확인합니다. `MyISAM` 테이블과 뷰에만 적용됩니다. `InnoDB` 는 무시됩니다.
`EXTENDED`	행마다 모든 키의 전체 키 조회를 수행합니다. 이렇게하면 테이블의 100 %의 무결성이 보장되지만 오랜 시간이 걸립니다. `MyISAM` 테이블과 뷰에만 적용됩니다. `InnoDB` 는 무시됩니다.

QUICK , MEDIUM , 또는 EXTENDED 옵션 중 하나가 지정되어 있지 않은 경우, 동적 포맷 MyISAM 테이블에 대한 기본 체크 타입은 MEDIUM 입니다. 그러면 그 테이블에 myisamchk --medium-Check tbl_name 을 실행 한 것과 동일한 결과를 얻을 수 있습니다. 또한 CHANGED 또는 FAST 가 지정되어 있지 않은 한, 정적 인 포맷 MyISAM 테이블에 대한 기본 검사 유형도 MEDIUM 입니다. 지정된 경우, 디폴트는 QUICK 입니다. CHANGED 와 FAST 의 경우 행은 거의 손상하지 않기 때문에, 로우 스캔은 생략됩니다.

체크 옵션은 다음의 예와 같이 결합 할 수 있습니다. 이 예에서는 테이블이 제대로 닫혔는지 여부를 판정하기 위해 그 테이블에 대해 빠른 검사를 실행합니다.

 CHECK TABLE test_table FAST QUICK;

참고

경우에 따라서는 CHECK TABLE 에 의해 테이블이 변경됩니다. 이것은 테이블이 "손상된"또는 "제대로 닫히지 않은"으로 표시되어 있지만, CHECK TABLE 로 테이블에 아무런 문제가 발견되지 않았던 경우에 발생합니다. 이 경우 CHECK TABLE 은 테이블을 정상으로 표시합니다.

테이블이 손상된 경우 가장 가능성이 높은 것은 데이터 부분이 아니라 인덱스의 문제입니다. 전 검사 유형은 인덱스를 철저하게 확인하기 위해 대부분의 오류를 찾을 수 있습니다.

정상으로 간주하는 테이블을 체크하는 것만의 경우 검사 옵션을 사용하지 않거나, 또는 QUICK 옵션을 사용하도록하십시오. 후자는 서둘러 중이고 QUICK 에서 데이터 파일의 오류를 찾을 수 없다는 아주 작은 위험을 감당할 때 사용하도록하십시오. (대부분의 경우 정상적인 사용 상황에서 MySQL 데이터 파일의 어떤 오류도 찾을 수 있습니다. 발견되면 그 테이블은 "손상된"으로 표시된 복구 될 때까지 사용할 수 없습니다 .)

FAST 및 CHANGED 은 주로 테이블을 가끔 체크하는 경우 스크립트에서 사용되는 (예를 들어, cron에서 실행되는) 것을 목적으로하고 있습니다. 대부분의 경우 FAST 는 CHANGED 보다 우선합니다. (우선되지 않는 유일한 경우는 MyISAM 코드에서 버그를 발견 한 것이 아닌가 의심되는 경우입니다.)

EXTENDED 는 일반적으로 검사를 수행했지만, MySQL이 행을 갱신하거나 키로 행을 검색하려고하면 계속 테이블에서 이상한 에러가 발생하는 경우에만 사용됩니다. 보통의 체크가 성공했을 경우, 이것은 거의 발생하지 않습니다.

CHECK TABLE ... EXTENDED 를 사용하면 쿼리 최적화 프로그램에서 생성 된 실행 계획에 영향을 미칠 수 있습니다.

CHECK TABLE 에 의해보고되는 다음의 몇 가지 문제는 자동으로 수정할 수 없습니다.

Found row where the auto_increment column has the value 0 .

이것은 AUTO_INCREMENT 인덱스 컬럼에 값 0이 포함 된 행이 테이블에 존재하는 것을 보여줍니다. ( AUTO_INCREMENT 컬럼이 0 인 행은 UPDATE 문을 사용하여 컬럼을 명시 적으로 0으로 설정하여 만들 수 있습니다.)

이것은 그 자체 오류는 아니지만 그 테이블을 덤프하고 복원하거나 그 테이블에 대해 ALTER TABLE 을 실행하려고 할 때 문제가 발생할 수 있습니다. 이 경우 AUTO_INCREMENT 컬럼은 AUTO_INCREMENT 컬럼 규칙에 따라 값을 변경하기 위해 중복 키 오류 등의 문제가 발생할 수 있습니다.

이 경고를 해결하려면, 단순히 그 컬럼을 0 이외의 아무것도의 값으로 설정하는 UPDATE 문을 실행합니다.

InnoDB 테이블

다음의주의 사항은 InnoDB 테이블에 적용됩니다.

CHECK TABLE 에서 InnoDB 테이블의 문제가 발견되면 서버는 오류의 전파를 방지하기 위해 종료 될 수 있습니다. 이 오류 정보는 오류 로그에 기록됩니다.
CHECK TABLE 은 InnoDB 테이블 또는 인덱스에 손상 또는 오류가 발생하면 오류를보고합니다. 서버를 종료 할 수 없습니다. MySQL 5.5에서는 인덱스 또는 테이블의 더 사용을 방지하기 위해 CHECK TABLE 은 일반적으로 인덱스를 손상된 것으로 표시하고 또한 그 테이블도 마찬가지로 표시 될 수 있습니다.
CHECK TABLE 은 보조 인덱스의 항목 수의 실수를 발견하면 오류를보고하지만 서버를 종료하거나 파일에 대한 액세스를 막거나하지 않습니다.
CHECK TABLE 은 인덱스 페이지의 구조를 조사하고 각 키 항목을 조사합니다. 키 포인터를 클러스터 된 레코드를 확인하고 BLOB 포인터의 경로를 따라하거나하지 않습니다.
InnoDB 테이블이 file-per-table 모드에서 자신의 .ibd 파일 에 저장되면 .ibd 의 처음 세 개의 페이지 에 테이블이나 인덱스 데이터가 아닌 헤더 정보가 포함되어 있습니다. CHECK TABLE 문은 헤더 데이터에만 영향을 미치는 불일치를 감지하지 않습니다. InnoDB .ibd 파일의 전체 내용을 확인하려면 innochecksum 명령을 사용합니다.
큰 InnoDB 테이블에서 CHECK TABLE 을 실행하면 CHECK TABLE 의 실행 중에 다른 스레드가 차단 될 수 있습니다. 시간 제한을 피하기 위해, CHECK TABLE 조작의 경우는 세마포어 대기 임계 값 (600 초)이 2 시간 (7200 초) 연장됩니다. InnoDB 는 240 초 이상 세마포어 대기를 감지하면 InnoDB 모니터의 출력을 오류 로그에 기록하기 시작합니다. 잠금 요청이 세마포어 대기 임계 값을 초과하여 연장 된 경우, InnoDB 는 그 프로세스를 중지합니다. 세마포어 대기가 완전히 제한 할 가능성을 방지하려면 CHECK TABLE 대신 CHECK TABLE QUICK 를 실행할 수 있습니다.