8.8.4 쿼리 성능 추정

대부분의 경우, 디스크 시크를 카운트하여 쿼리 성능을 추정 할 수 있습니다. 작은 테이블의 경우 일반적으로 1 번 디스크 검색에서 레코드를 찾을 수 있습니다 (인덱스가 캐시되어있을 가능성이 높기 때문에). 큰 테이블의 경우 B 트리 인덱스를 사용하여 그것을 추정 할 수 있지만 행을 찾기 위해 이렇게 많은 탐색이 필요합니다. log( row_count ) / log( index_block_length / 3 * 2 / ( index_length + data_pointer_length )) + 1 .

MySQL은 인덱스 블록이 통상 1,024 바이트 데이터 포인터는 4 바이트입니다. 3 바이트의 키 값 길이 ( MEDIUMINT 크기)의 500,000 행 테이블의 경우,이 공식은 log(500,000)/log(1024/3*2/(3+4)) + 1 = 4 탐색을 나타냅니다.

이 인덱스는 약 500,000 * 7 * 3/2 = 5.2M 바이트 (2/3 일반적인 인덱스 버퍼 충전율 것으로 가정)의 스토리지가 필요하기 때문에 인덱스를 많이 메모리에 넣어 가능 성이 높고 데이터를 읽고 행을 찾기 위해 하나 나 둘 개의 호출 만하면됩니다.

그러나 쓰기는 새로운 인덱스 값의 위치를​​ 찾기 위해 4 개의 탐색 요청 및 인덱스 업데이트 및 행 쓰기에 보통 2 번의 탐색이 필요합니다.

이전 설명은 응용 프로그램의 성능이 log N 씩 서서히 감소하는 것을 의미하는 것은 아닙니다. OS 또는 MySQL 서버가 모든 캐시되는 한, 테이블이 커져도 조금 느려질뿐입니다. 데이터가 캐시 할 수 없을 정도로 커질 응용 프로그램이 디스크 검색 (이것은 log N N 씩 증가)에 의해서만 제한 될 때까지 현저하게 느려지기 시작합니다. 이를 방지하려면 데이터 증가에 맞춰 키 캐시를 늘립니다. MyISAM 테이블에서 키 캐시 크기는 key_buffer_size 시스템 변수에 의해 제어됩니다. 섹션 8.11.2 "서버 파라미터의 튜닝」 을 참조하십시오.