모든 MySQL InnoDB 테이블이 조각난 이유는 무엇입니까?


10

어떤 이유로 mysqltuner를 실행할 때 MySQL 서버의 모든 InnoDB 테이블이 조각으로 나열됩니다. 몇 시간 전에 서버를 설치했으며 (OSX Lion에) 배치 파일에서 가져온 새로운 데이터가 많이 있습니다.

한 데이터베이스의 모든 테이블을 MYISAM으로 변환하려고 시도했으며 조각난 테이블 수가 충분히 줄었습니다. 이상하게도, 해당 테이블을 InnoDB로 다시 변환하자마자 조각난 테이블 수가 다시 백업되었습니다. 이것은 지금까지의 연구와 달리 실행 ALTER TABLE table_name ENGINE=INNODB;이 조각화를 수정해야 함 을 시사합니다 .

약간의 인터넷 검색 후 나는 달렸다.

SELECT table_schema, table_name, data_free/1024/1024 AS data_free_MB 
FROM information_schema.tables
WHERE engine LIKE 'InnoDB' AND data_free > 0

아마도 모든 조각난 테이블을 나열합니다 (실제로 조각난 테이블 수에 대한 mysqltuner 출력과 동일한 수의 결과를 반환합니다). 모든 단일 항목은 data_free_MB열 에서 정확히 같은 숫자를 갖습니다 (현재 7.00000000).

이것은 실제로 실제 문제입니까, 아니면 mysqltuner가 잘못하고 있습니까? 문제가 있으면 어떻게 해결합니까?

편집하다

나는 바보이고 7MB 조각화는 각 테이블이 아니라 전체 파일에 대한 것임을 점점 더 의심하고 있습니다. 그럴 경우 누구나 확인할 수 있습니까?


당신은 정말로 7 free MB가 문제라고 생각합니까?
David Schwartz

@DavidSchwartz 단서가 아니기 때문에 내가 묻는 이유는;) 각각 7MB의 여유 공간이있는 2314 개의 테이블이 있으며 그 의미를 모릅니다. mysqltuner가 왜 우려의 원인이 아닌지 그 그림을 보여줄지 모르겠습니다. 나는 여기 누군가가 숫자를받는 것에 대해 어떻게 걱정하는지, 그리고 '표준'방법이 효과가 없기 때문에 문제를 완화하기 위해 할 수있는 일을 말해 줄 수 있기를 바랐습니다.
Clive

플래그에서 사용자의 요청에 따라이 질문을 마이그레이션합니다.
Daniel Beck

mysqltuner가 보여주는 대부분의 세부 사항은 정보 용입니다. 모든 것이 문제가되는 것은 아닙니다. 그것이 문제라면 분명히 그렇게 말할 것입니다. 이것이 문제로 표시 되었습니까?
John Gardeniers

@JohnGardeniers 믿습니다. 메시지는 다음 [!!] Total fragmented tables: 2314과 같습니다.. 문제가 있음을 확신합니다 (빨간색 느낌표가 있음)
Clive

답변:


5

위의 의견에 따라 sqltuner의 모든 출력이 오류를 나타내는 것은 아닙니다. 스크립트가 일반적으로 다음 줄에서 문제라고 밝히지 않는 한, 치료에 대한 제안이 뒤 따르지 않으면 정보 항목 일뿐입니다.


3

innodb_file_per_table 을 활성화 하면 새 InnoDB 테이블이 외부 .ibd파일에 작성되도록 프로토콜을 설정하기 만하면 됩니다. 이전에 생성 한 모든 InnoDB 테이블은 여전히 ​​ibdata1에 포함됩니다.

innodb_file_per_table을 비활성화하면 실행할 때마다

ALTER TABLE table_name ENGINE=INNODB;

테이블 데이터와 인덱스 페이지를 ibdata1에 추가하기 만하면됩니다. 이렇게하면 테이블이 연속 페이지에 존재하고 조각화가 제거됩니다. 단점은 ibdata1이 빠르게 커진다는 것입니다.

추천

모든 데이터를 내보내고 ibdata1, ib_logfile0, ib_logfile1을 제거한 후 다시로드해야합니다.

나는 이것을 어떻게 그리고 왜 썼는지

업데이트 2012-08-15 12:05 EDT

mysqltuner.pl 스크립트 자체를 살펴볼 수 있습니다. IMHO 나는 그것이 조각화를 측정하기 위해 오래된 공식을 사용하고 있다고 생각합니다. 최신 버전의 mysqltuner가 있는지 확인하십시오.

외부에 저장된 InnoDB 테이블의 조각화를 측정하기 위해 2012 년 4 월 11 일에 그에 대한 게시물을 썼습니다 (2012 년 4 월 19 일 하단의 업데이트 참조)


1
알았어, 이제 상황이 훨씬 더 이해가 되네, 고마워 결국 데이터를 내보내고 MySQL을 완전히 지우고 다시 설치했습니다 (그러나 innodb_file_per_table서버를 시작하고 다시 가져 오기 전에 conf 파일에 추가 ). 그 전에는 모든 종류 의 InnoDB 오류 (실제로 나쁜 종류 ... innodb_force_recovery데이터를 꺼내기 위해 레벨 6에서 실행해야한다는 것을 의미 했습니다!)를 얻었으며 모든 종류의 '로그 파일 날짜는 미래!' 오류. 그것들은 지금 멈춘 것처럼 보이지만 여전히 몇 개의 조각난 테이블이 있습니다. 입력에 다시 한 번 감사드립니다
Clive

대박! 이것은 매우 유익합니다. 감사합니다 @RolandoMySQLDBA!
Sudhi
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.