이 장에서는 간접 쿼리 최적화를 다룬다. 세 가지 비밀 인덱스가 도움이 되지 않을 수 있다 인덱스는 성능에서 핵심이지만 좋은 인덱스라도 쿼리가 느릴 수 있다. 인덱스 없이는 성능을 달성할 수 없지만 무한한 데이터 크기에 대해 무한한 영향력을 제공한다는 의미는 아니다. 인덱스 스캔의 경우 테이블의 행 수가 증가할수록 인덱스 스캔을 사용하는 쿼리에 대한 응답 시간도 늘어나므로 반드시 지연 시간이 발생한다. 더 이상 최적화할 수 없으면 간접 쿼리 최적화를 한다. 행 찾기의 경우 아래 나열된 것 처럼 한 행만 일치하는 인덱스 조회 접근 유형이 아니라면, rows 필드에 주의를 기울여야 한다....
성능 향상과 관련 없는 딴짓 레드헤링(Red Herring): 목표로부터 주의를 딴 데로 돌리는 상황 MySQL 성능을 향상하기 위한 방법을 찾을 때 일반적으로 두 가지 레드헤링이 있다. 하드웨어를 구매하는 것 MySQL 튜닝 더 좋고 빠른 하드웨어! MySQL 성능이 만족스럽지 않을 때 성능 향상에 도움이 되는지 확인하기 위해 스케일업부터 시작하지 말라. 이 경우가 합리적인 2가지 상황 하드웨어 성능 부족으로 명백하게 느린 경우 예) 500GB의 데이터에 1GB의 메모리를 사용하는 경우 애플리케이션의 사용량이 급증하고 있으며, 하드웨어 스케일업이 애플리케이션 실행에 있어 안정성을 담보하기 위한 임시 방편인 경우 단순 스케일업은 아무것도 배우지 못하며, 고사양의 하드웨어 구매로 문제를 대강 뭉개는 데 익숙해질 것이다....
성능은 곧 쿼리 응답 시간 쿼리 응답 시간: MySQL이 쿼리를 실행하는 데 소요되는 시간 같은 의미: 응답 시간, 쿼리 시간, 실행 시간, 쿼리 지연 시간 소요 시간: MySQL이 쿼리를 받았을 떄 시작되고 셜과 세트를 클라이언트에 전송한 시점까지의 경과 시간 핵심 지표 갑작스럽게 벌어진 MySQL 성능 저하 현상은 여러 가지를 고려해야 해서 해결 방법을 파악하기 어려울 수 있다. 또한 MySQL 전문가가 아닌 응용 프로그램 엔지니어라면 이 문제가 크게 느껴질 수 있다....