동등 조건으로 인덱스를 사용하는 나쁜 SQL 문 튜닝 전 SQL 문 select * from 사원출입기록 where 출입문 = 'B' 튜닝 전 실행계획 explain select * from 사원출입기록 where 출입문 = 'B' I_출입문 인덱스를 사용해서 데이터에 접근한다. 명확한 상수화 조건으로 데이터 접근 범위를 줄였기때문에 ref 항목이 const로 출력된다. (*) MariaDB 신버전의 경우 ALL 타입(테이블 풀 스캔)으로 출력된다. 튜닝 수행 select 출입문, count(1) from 사원출입기록 group by 출입문 튜닝 후 SQL 문 select * from 사원출입기록 ignore index(I_출입문) where 출입문 = 'B' 출입문 B는 총 66만 건 전체 데이터 중 ..

인덱스 고려없이 열을 사용하는 나쁜 SQL 문 튜닝 전 SQL 문 select 성, 성별, count(1) as 카운트 from 사원 group by 성, 성별 튜닝 전 실행 계획 explain select 성, 성별, count(1) as 카운트 from 사원 group by 성, 성별 I_성별_성 인덱스키를 가지고 인덱스 풀스캔(Using index)으로 접근한다. 성과 성별 컬럼 순으로 재정렬하기위해 Using temporary 를 사용한다. 사원 테이블의 인덱스 show index from 사원 튜닝 전 SQL 문에서 사원테이블의 I_성별_성 인덱스를 활용하는데도 메모리나 디스크에 임시 테이블을 꼭 생성해야할지 고민해야한다. I_성별_성 인덱스는 성별과 성 컬럼순으로 생성된 오브젝트로 해당 인덱스..

습관적으로 중복을 제거하는 나쁜 SQL문 튜닝 전 SQL문 select distinct 사원.사원번호, 사원.이름, 사원.성, 부서관리자.부서번호 from 사원 join 부서관리자 on (사원.사원번호 = 부서관리자.사원번호) 튜닝 전 실행계획 explain select distinct 사원.사원번호, 사원.이름, 사원.성, 부서관리자.부서번호 from 사원 join 부서관리자 on (사원.사원번호 = 부서관리자.사원번호) 테이블 id값이 둘 다 1로 서로 조인하고 있으며 부서관리자 테이블은 인덱스 풀 스캔, 사원 테이블은 사원번호라는 기본키를 사용해서 단 1건의 데이터 조회하는 방식으로 조인 distinct() 를 위해 별도 임시테이블 (extra 항목 : Using temporary)을 생성 (*) ..

형변환으로 인덱스를 활용하지 못하는 나쁜 SQL 문 튜닝 전 SQL 문 select count(1) from 급여 where 사용여부 = 1; 튜닝 전 분석 explain select count(1) from 급여 where 사용여부 = 1; 인덱스 확인 필요 show index from 급여; 테이블 구조 확인 필요 desc 급여; 조건문에 사용되는 사용여부 열 값이 숫자 타입으로 써서 데이터에 접근해서 DBMS 내부의 묵시적 형변환이 발생했다 따라서 형변환이 발생하지 않도록 SQL문을 조정해야 한다. 튜닝 후 SQL select count(1) from 급여 where 사용여부 = '1'; 실행계획 explain select count(1) from 급여 where 사용여부 = '1'; I_사용여부 ..

실습관련 기본 세팅 워크벤치 메뉴 > Edit > Preferences SQL Execution: Limit Rows 체크 해제 및 카운트 999999 로 설정 (*) 기본적으로 1000 로우값 출력이 기본으로 세팅되어있음 SQL 튜닝 준비하기 각 테이블별 인덱스 목록 급여 PK INDEX 부서 PK INDEX 부서관리자 PK INDEX 부서사원_매핑 PK INDEX 사원 PK INDEX INDEX 사원출입기록 PK INDEX INDEX INDEX 직급 PK (*) 고유 인덱스 : UI_로 시작 (Unique Index) (*) 비고유 인덱스 : I_로 시작 (Index) 인덱스 정보 확인 show index from 테이블명; SQL문 단순수정으로 착한쿼리 만들기 기본 키를 변형하는 나쁜 SQL문 튜닝..