10.8.5 Estimating Query Performance

10.8.5 Estimating Query Performance

대부분의 경우, 디스크 탐색 횟수를 계산함으로써 쿼리 성능을 추정할 수 있습니다. 작은 테이블의 경우, 보통 한 번의 디스크 탐색으로 row를 찾을 수 있습니다(왜냐하면 인덱스가 아마도 캐시되어 있기 때문입니다). 더 큰 테이블의 경우, B-tree 인덱스를 사용한다고 가정하면 row를 찾기 위해 필요한 탐색 횟수는 다음과 같이 추정할 수 있습니다: log(row_count) / log(index_block_length / 3 * 2 / (index_length + data_pointer_length)) + 1.

MySQL에서 인덱스 블록은 보통 1,024 byte이고 데이터 포인터는 보통 4 byte입니다. key value 길이가 3 byte인(크기가 MEDIUMINT인) 500,000-row 테이블의 경우, 이 공식은 다음과 같이 나타냅니다: log(500,000)/log(1024/3*2/(3+4)) + 1 = 4회 탐색입니다.

이 인덱스는 약 500,000 * 7 * 3/2 = 5.2MB의 저장 공간을 필요로 합니다(일반적인 인덱스 버퍼 채움 비율이 2/3이라고 가정). 따라서 인덱스의 상당 부분이 메모리에 있게 되고, row를 찾기 위해서는 데이터를 읽기 위한 호출이 한두 번이면 충분합니다.

그러나 쓰기 작업의 경우, 새로운 인덱스 값을 어디에 배치할지 찾기 위해 네 번의 탐색 요청이 필요하고, 일반적으로 인덱스를 갱신하고 row를 쓰기 위해 두 번의 탐색이 필요합니다.

앞선 설명이 애플리케이션 성능이 log _N_에 따라 서서히 악화된다는 것을 의미하지는 않습니다. 모든 것이 OS 또는 MySQL 서버에 의해 캐시되는 한, 테이블이 커져도 성능 저하는 미미한 수준에 그칩니다.

데이터가 너무 커져서 캐시될 수 없게 되면, 디스크 탐색에만 묶이게 될 때까지 성능이 훨씬 더 느려지기 시작합니다(이 탐색 횟수는 log _N_에 따라 증가합니다). 이를 피하기 위해서는 데이터가 증가함에 따라 키 캐시 크기를 늘려야 합니다. MyISAM 테이블의 경우 키 캐시 크기는 key_buffer_size 시스템 변수로 제어됩니다. Section 7.1.1, “Configuring the Server”를 참조하십시오.