7.1. 최적화 개요

7.1.1. MySQL 디자인 상의 제약 사항 and 트레이드오프 (Tradeoff)

7.1.2. 어플리케이션이 이식성 (Portability)을 갖도록 만들기

7.1.3. MySQL 벤치마크 슈트

7.1.4. 여러분 자신의 벤치마크 사용하기

시스템의 성능은 무엇보다도 시스템의 기본 디자인을 어떻게 하느냐에 달려 있다. 여러분은 사용 중에 있는 시스템이 어떤 종류의 프로세싱을 하고 있는지, 그리고 어떤 병목 현상 (bottleneck)이 발생하는지에 대해서도 알고 있어야 한다. 대부분의 경우, 시스템 병목 현상은 아래와 같은 곳에서 발생하게 된다:

• 디스크 검색 (Disk seeks). 디스크는 데이터 조각을 찾는데 시간을 소비한다. 최신의 디스크들은, 평균 검색 시간이 보통10ms 이하이기 때문에, 이론적으로 초당 약 100개의 검색 (seek)을 수행할 수가 있다. 이 시간은 점진적으로 개선되고 있으며 단일 테이블에 대해 이것을 최적화 시키기는 매우 어렵다. 검색 시간을 최적화 할 수 있는 방법은 데이터를 한 개 이상의 디스크에 분산하는 것이다.
• 디스크 읽기 and 쓰기. 최신의 디스크들은 하나의 디스크가 최소 10–20MB/s의 처리량 (throughput)을 가지고 있다. 여러 개의 디스크에서 병렬로 데이터를 읽을 수 있기 때문에 디스크 검색 보다는 쉽게 최적화를 시킬 수가 있다.
• CPU 싸이클 (cycle). 데이터가 메인 메모리에 있을 때 그것을 처리해서 결과를 얻는다. 메모리에 비해 작은 양의 테이블을 가지도록 만드는 것이 가장 일반적인 제약 요소이다. 하지만 작은 테이블을 가지고 있다면, 속도는 문제가 되지 않는다.
• 메모리 대역폭 (Memory bandwidth). CPU가 자신의 캐시가 보유할 수 있는 양보다 많은 데이터를 필요로 하게 되면, 메인 메모리 대역폭에서 병목 현상이 발생한다. 대부분의 시스템에서는 일반적으로 이러한 현상이 발생하지는 않지만, 이 점에 대해서는 인지를 하고 있어야 한다.