대소문자가 섞인 데이터와 비교하는 나쁜 SQL문 튜닝 전 SQL문 튜닝 전 SQL문은 사원테이블에서 입사일자가 1990년 이후이고 이름이 MARY인 사원정보를 조회하는 쿼리로 MARY와 1990-01-01은 화면에서 입력된 변숫값이므로 매번 입력되는 영문의 대소문자는 고정되지 않는다. select 이름, 성, 성별, 생년월일 from 사원 where lower(이름) = lower('MARY') and 입사일자 >= STR_TO_DATE('1990-01-01', '%Y-%m-%d') 튜닝 전 실행계획 where 조건문에 이름과 입사일자 컬럼이 명시되어 있지만 테이블 풀 스캔으로 수행된다 이름 컬럼은 기본적으로 lower() 함수가 가공하므로 이름 컬럼으로 만들어진 인덱스가 존재하더라도 활용은 불가능하다...

인덱스를 하나만 사용하는 나쁜 SQL 문 튜닝 전 SQL 문 select * from 사원 where 이름 = 'Matt' or 입사일자 = '1987-03-31' 튜닝 전 쿼리라고 해도 짧은 소요시간만을 기준으로 삼지않으며 더 나은 쿼리로 개선할 수 있다면 튜닝대상이 된다. 튜닝 전 실행계획 explain select * from 사원 where 이름 = 'Matt' or 입사일자 = '1987-03-31' 사원 테이블은 테이블 풀 스캔(ALL) 으로 처리된다. 튜닝 수행 조건절에 해당하는 데이터 분포 확인 이름=Matt : 233 건 입사일자=1987-03-31 : 111건 전체 데이터가 약 30만 건에 달하는 사원 테이블의 데이터 건수와 비교했을 때 이름 컬럼과 입사일자 컬럼의 조건절에서 조회하는 ..

필요 이상으로 많은 정보를 가져오는 나쁜 SQL 문 튜닝 전 SQL 문 select count(사원번호) as 카운트 from ( select 사원.사원번호, 부서관리자.부서번호 from ( select * from 사원 where 성별 = 'M' and 사원번호 > 300000 ) 사원 left join 부서관리자 on 사원.사원번호 = 부서관리자.사원번호 ) 서브쿼리; 튜닝 전 실행계획 id가 1인 행만 있으므로 먼저 출력된 사원테이블이 데이터에 접근하는 드라이빙 테이블이고 나중에 출력된 부서관리자 테이블이 드리븐 테이블임을 알 수 있다. 사원 테이블은 사원번호 > 300000 조건때문에 레인지스캔을 수행하며 기본키를 활용해서 데이터에 접근할 것임을 알 수 있다. 부서관리자 테이블은 사원.사원번호 =..

DEPENDENT SUBQUERY UNION 또는 UNION ALL 을 사용하는 서브쿼리가 메인테이블에 영향을 받는 경우로, UNION 으로 연결된 단위 쿼리들 중에서 처음으로 작성한 단위쿼리에 해당되는 경우이다. UNION으로 연결되는 첫번째 단위쿼리가 독립적으로 수행하지 못하고 메인테이블로부터 값을 하나씩 공급받는 구조이므로 성능적으로 불리하여 SQL문이 튜닝대상이 된다. explain select 관리자.부서번호, ( select 사원1.이름 from 사원 as 사원1 where 성별 = 'F' and 사원1.사원번호 = 관리자.사원번호 union all select 사원2.이름 from 사원 as 사원2 where 성별 = 'M' and 사원2.사원번호 = 관리자.사원번호 ) as 이름 from ..

PRIMARY explain select 사원1.사원번호, 사원1.이름, 사원1.성 from 사원 as 사원1 where 사원1.사원번호 = 100001 union all select 사원2.사원번호, 사원2.이름, 사원2.성 from 사원 as 사원2 where 사원2.사원번호 = 100002; SUBQUERY 독립적으로 실행되는 서브쿼리로 SELECT절의 스칼라 서브쿼리와 WHERE 절의 중첩 서브쿼리일 경우에 해당 explain select ( select count(*) from 부서사원_매핑 as 매핑 ) as 카운트, ( select max(연봉) from 급여 ) as 급여; 2번과 3번의 id값의 서브쿼리는 각각 독립적으로 실행된다. DERIVED FROM 절에 작성된 서브쿼리로 FROM ..

실행 계획 수행 SQL문으로 요청한 데이터를 어떻게 조회할 것인지에 대한 계획, 즉 경로에 대한 계획이다. (*) 여기서부터는 GUI인 MYSQL 워크벤치를 사용 기본실행계획 수행문 : 아래 아무거나 사용해도 된다. 개인적으로 EXPLAIN 사용 EXPLAIN SQL문; DESC SQL문; 실행계획 수행 SQL문 앞에 EXPLAIN 키워드를 입력하고 실행하면 옵티마이저가 만든 실행계획이 출력된다. use tuning; show tables; explain select * from 사원 where 사원번호 between 100001 and 200000; (*) 마리아 DB 버전 10.0.5 이상에서는 UPDATE 및 DELETE 문에서도 실행계획을 확인할 수 있다. 기본 실행계획 항목 분석 EXPLAIN ..