우리집앞마당

1번 포스팅에 이어서 작성한다. 5. possible_keys옵티마이저는 어떤 인덱스를 사용할지 후보들을 정해놓고 그중에 하나를 사용하는데 possible_keys는 후보에서 떨어진 인덱스 키들을 보여준다. 강제로 인덱스를 태우고자할때는 유용할 수도 있을것 같으나 일단 수립된 계획을 확인할때는 상대적으로 비중이 떨어지는 항목이다. 6. keypossible_keys가 탈락한 키들의 집합이라면 key는 뽑힌 인덱스키를 보여준다. index_merge 처럼 다중 인덱스를 활용한 경우가 아니라면 값은 항상 1개를 표현한다. 7. key_len사용된 키의 컬럼크기를 나타낸다. character set에 따라 같은 컬럼이라도 다르게 표현될 수 있으며, null 유무에 따라서도 크기가 달라질 수 있다. 8. ref..

쿼리 앞에 EXPLAIN 키워드를 붙이면 실행 계획을 확인 할 수 있다. EXPLAIN SELECT * FROM test; 실행 계획은 일반 조회 쿼리 처럼 테이블 형태로 출력되는데 간단하게 그 내용을 정리해본다. 1. idSELECT 쿼리에 부여되는 아이디. 한 SELECT 쿼리 내에 복수개의 SELECT 문이 서브쿼리(Sub Query) 형태로 들어갈 수 있으므로 그런 경우에 id 값이 증가되어 여러행의 실행계획이 나타나게 된다. SELECT 문이 1개만 존재하는 JOIN(조인) 형태의 쿼리는 복수의 id가 부여되지 않는다. 2. select_type-SIMPLE명칭 그대로 심플한 쿼리이다. 서브쿼리같은 복잡함이 없다. -PRIMARY서브쿼리가 존재할때 가장 바깥 쿼리를 뜻한다. 복수 행의 실행계획에..

요즘 통계쪽 쿼리를 짜게되면서 DB를 공부하고있다. 보통 쿼리를 짜게되면 실행계획을 확인 한 후 쿼리를 튜닝하여 효율성 높은 쿼리를 짜게되는데 이번에 포스팅할 내용은 그 실행계획을 빠르게 수집하는 법이다. 쿼리에 2개 이상 테이블의 join이 들어갈 경우 어떤 테이블을 기준으로 조인을 거는지에 따라 수행시간이 엄청나게 차이가 날 수 있는데 이때 최적화된 조인을 위한 알고리즘은 2가지가 존재한다. 1. Exhaustive Search(철저한 탐색) 모든 경우의 수에 해당하는 비용을 계산한 후 최적의 조합을 찾는다. 확실하게 최적의 조합을 찾을 순 있겠으나 모든 경우의 수를 구하는 만큼 효율적이라고 보기 힘들다. 2. Greedy Search(탐욕스러운 탐색) optimizer_search_depth 변수에..