Mysql Docs 맛보기

 

최근 공부로 Real MySql을 읽고 있었다.

문득 이런 생각이 들었다.

"java, spring docs는 많이 보는데 mysql docs를 왜 한번도 안봤을까?"

그렇다 RealMySql 책에서도 레퍼런스로 dev.mysql이 있었지만 찾아보지 못했다. 아니 안할걸지도..

개발자로써 부끄러운 일이지만 이제라도 Mysql Docs를 보려 한다. 

같이 찍먹해보자!

 

dev.mysql.com으로 접속하면 Reference Manual 로 접속한다.

 

필요한 부분을 검색해서 Docs를 살펴본다.

난 최근 옵티마이저가 궁금하니 찾아봐야겠다.

구글 번역으로 보니 몇개가 이상하지만 꽤 잘되어 있다.

 

mysql docs에서는 쿼리 최적화에 대한 고려 사항을 꽤나 디테일하게 알려 준다.

• 인덱스를 추가 할 수 있는지 여부를 확인해보기, 인덱스는 검색 속도를 높여준다.
• 오래 걸리는 함수 호출과 같은 쿼리부분을 격리하고 조정하기, 함수는 결과 집합의 모든 행에 대해 한 번 호출되거나 테이블의 모든 행에 대해 한 번 호출될 수 있으므로 비효율성이 있다.
• 큰 테이블의 경우 쿼리에서 전체 테이블 스캔 수를 최소화 하기
• 주기적으로 통계테이블쿼리을 사용하여 테이블 통계를 최신 상태로 유지하면 ANALYZE TABLE옵티마이저가 효율적인 실행 계획을 구성하는 데 필요한 정보를 가지게 된다.
• 스토리지 엔진에 특정한 튜닝 기술, 인덱싱 기술 및 구성 매개변수에 대해 알아보기, 8.5.6, “InnoDB 쿼리 최적화” 및 8.6.1, “MyISAM 쿼리 최적화”를 참조
• 쉽게 해결되지 않는 경우 기본지침으로 실행계획을 읽고 인덱스, where절, 조인절을 조정하기
• 캐시 메모리 영역을 사용하여 빠르게 실행되는 쿼리의 경우에도 더 적은 캐시 메모리가 필요하도록 추가로 최적화하기
• 잠금문제 처리하기

 

WHERE절 최적화

where절 최적화하기!

가독성을 희생하면서 쿼리를 작성하고 싶을 수 있지만 Mysql은 유사한 최적화를 자동으로 수행하기 때문에 굳이 그러지 않아도 된다.

그러니 이해하기 쉽고 유지 관리하기 쉬운 형식으로 쿼리를 남겨두자.

 

각 테이블 인덱스가 실행되고 옵티마이저가 테이블 스캔을 사용하는 것이 비효율이라고 판단되면 최상의 인덱스가 사용됩니다. 예전에는 최상의 인덱스가 테이블의 30% 이상에 걸쳐 있는지 여부에 따라 스캔이 사용되었지만 더 이상 고정 비율이 인덱스 또는 스캔 사용 사이의 선택을 결정하지 않습니다. 옵티마이저는 더 복잡해졌기 때문에 테이블 크기, 행 수 및 I/O 블록 크기와 같은 추가 요소에 대한 예측을 기반으로 합니다.

 

이번엔 Mysql Docs에서 최적화 부분을 아주 잠깐 동안 살펴 보았다.

쿼리 성능 문제가 생겼을때 기초지식이 없으면 빠르게 대처하기 어렵다.

그러므로 개발자라면 디비에 대한 충분한 지식과 이해가 필요하다.

앞으로 틈틈히 읽어 보자!