7.2. SELECT and 다른 명령문 최적화 하기
7.2.1. EXPLAIN을 사용해서 쿼리 최적화 하기
7.2.2. 쿼리 성능 추정하기
7.2.3. SELECT 쿼리의 속도
7.2.4. WHERE 구문 최적화 하기
7.2.5. 범위 최적화 하기
7.2.6. 인덱스 병합 최적화 하기
7.2.7. IS NULL 최적화 하기
7.2.8. LEFT JOIN and RIGHT JOIN 최적화 하기
7.2.9. 네스티드 조인 최적화 하기
7.2.10. 외부 (outer) 조인 단순화
7.2.11. ORDER BY 최적화 하기
7.2.12. GROUP BY 최적화 하기
7.2.13. DISTINCT 최적화 하기
7.2.14. IN/=ANY 서브 쿼리 최적화 하기
7.2.15. LIMIT 최적화 하기
7.2.16. 테이블 스캔을 피하는 방법
7.2.17. INSERT 명령문의 속도
7.2.18. UPDATE 명령문의 속도
7.2.19. DELETE 명령문의 속도
7.2.20. 기타 최적화 팁 (Tips)
우선, 하나의 요소 (factor)가 모든 명령문에 영향을 준다: 퍼미션 (permission) 설정을 복잡하게 하면 할수록, 더 큰 오버헤드 (overhead)가 발생한다. GRANT 명령문을 사용할 때 보다 단순한 퍼미션을 사용하는 것이 클라이언트가 명령문을 실행할 때 퍼미션-검사 오버헤드를 낮추는 방법이다. 예를 들면, 테이블 레벨 또는 컬럼 레벨의 권한에 대해서는 전혀 승인을 하지 않으면, 서버는 tables_priv and columns_priv 테이블에 대해서는 전혀 검사를 하지 않게 된다. 비슷하게, 여러분이 어느 계정에 대해서는 자원 제한을 하지 않으면, 서버는 자원 카운팅을 실행하지 않는다. 만일 여러분이 매우 큰 명령문-처리 업무를 해야 한다면, 퍼미션-검사 오버헤드를 줄일 수 있도록 단순화된 승인 구조를 사용하는 것이 효율적인 것이다.
만일 특정 MySQL 수식 또는 함수에 문제가 있다면, mysql 클라이언트 프로그램을 사용해서 BENCHMARK() 함수를 호출하여 타이밍 테스트를 하도록 한다. 이것의 신텍스는 BENCHMARK(loop_count,expression)이다. 리턴 값은 항상 0 이다:
mysql> SELECT BENCHMARK(1000000,1+1);
+------------------------+
| BENCHMARK(1000000,1+1) |
+------------------------+
| 0 |
+------------------------+
1 row in set (0.32 sec)
이 결과 값은 펜티엄(Pentium) II 400MHz 시스템을 가지고 얻은 것이다. 이것은 MySQL이 이 시스템에서 1,000,000개의 단순 추가 수식 (simple addition expression)을 처리하는데 0.32초가 걸렸다는 것을 나타내는 것이다.
모든 MySQL 함수는 고도로 최적화가 되어 있으나, 몇가지 예외는 있다. BENCHMARK()는 쿼리에 문제가 있을 경우에 이를 찾아내는 훌륭한 툴이다.