MySQL 통계정보 갱신

ANALYZE TABLE

테이블 유지 보수의 대명사라고하면, 인덱스 통계 업데이트는 아닐까. 작업을 계속 사이에, 부지불식간 인덱스 통계가 미쳐 버려하고 성능이 나오지 않는다. RDBMS에는 그런 문제가 붙 것이지만, InnoDB의 경우 ANALYZE TABLE은 불필요하다. 왜냐하면 InnoDB가 자발적으로 통계 정보를 업데이트하기 때문이다. InnoDB는 다음의 조건에 적합하면 ANALYZE TABLE을 자동으로 실시하는 구조로되어있다.

• 지난 인덱스 통계를 업데이트 한 후 테이블의 행 전체의 1/16이 업데이트되었다.
• 지난 인덱스 통계 정보를 업데이트하고, 20 억 이상의 행 업데이트되었다.

그래서, 일반 사용자라면별로 인덱스 통계 업데이트에 대한 걱정은 할 필요 없을 것이다. (여기서 남편의 AA 'こまけぇこ했다 만 괜찮아! "를 삽입하고 싶은 곳이지만, 굳이 자중 해두기로한다.) 날카로운 사람은 여기에서 "なにっ?! 마음대로 ANALYZE TABLE이 달리고 버리면 처리가 멈춰 버리는 것은!?」 라고 생각 될지도 모른다. 하지만 그것도 걱정 무용하다. InnoDB의 인덱스 통계 업데이트 작업은 비교적 (또는 매우) 가벼운 처리이다. 전체 테이블을 스캔하는 일은하지 않고 무작위로 페이지를 8 회 추출하고 그 페이지에 포함 된 행 데이터를 검사하여 인덱스의 통계 정보를 근사한다. 근사치이므로 정확한 통계는 아니지만, MySQL의 최적화를 이용하려면 충분한 정도 인 것이다. 8 번의 샘플링을 각 인덱스마다하기 때문에 인덱스가 많아지면 인덱스 통계 업데이트는 무거운 처리가 될지도 모른다. 특히 페이지가 InnoDB 버퍼 풀에 타고 있지 않은 경우에는 디스크의 Read까지 발생 해 버린다. されど고작 8 페이지 인 것이다. (하지만 Facebook이되면 과연 효과가 나온다 보인다.) MySQL 5.1의 내장 InnoDB는 "본 8 회 샘플링 '이라는 고정이다. InnoDB Plugin에서는 샘플 수를 조정할 수 있도록되어있다. 페이지를 무작위로 추출하기 위해 우연히 편향의 큰 페이지만을 추출하여 버리는 확률은 0이 아니다. 근사 인 이상 그것은 어쩔 수없는 것이지만, MySQL이 수립 실행 계획에 영향을 줄 경우는 확률 적으로 전무는없는 것이다. 만약 실행 계획이 형편되어 버린 경우에는 ANALYZE TABLE 명령을 수동으로 실행하고 InnoDB Plugin이면 innodb_stats_sample_pages 옵션을 조정하면 좋을 것이다. 여담이지만, 인덱스 통계는 테이블 공간에는 기록되지 않는다. 테이블을 open 할 때 계산되는 것이다. 따라서 테이블 캐시가 적은 경우에는 자주 인덱스 통계가 다시 계산되므로주의하자. 참고 : Controlling Optimizer Statistics Estimation