. 인프런 온라인 교육 : https://www.inflearn.com
. 행 수 추정 (Cardinality Estimation)
- 집합의 원수 (데이터 레코드)
- 처리 예상 행 수 추정 (잘 할 수 있도록 하는 것이 쿼리 튜닝이다)
- 밀도 : 열의 유일 값
. 1 / 열의 유일 값 개수 = ? (값이 1에 가까울 수록 중복 데이터가 많은 것)
- 선택도 :
. 결과 행 수 / 테이블 행 수 = ? (값이 작을 수록 선택도가 좋다)
. OLTP (트랜젹션용 작업용 쿼리) : 빠른 응답 속도 목표, 단일 CPU 사용 충분, Index Seek
. OLAP (통계 및 대용량 작업 쿼리) : 전체 처리 성능 목표, 병렬 처리 필요, 하드웨어 성능, Index Scan
. 2014 버전 이상 사용 권장 (미만 버전 성능 버그가 많음)
. 내부 함수 사용 시 행 수 추정이 좋지 않은 경우가 많음
. 쿼리 튜닝 : 인덱스 튜닝, 쿼리 자체 튜닝, 리소스 대기 튜닝 (CUP, RAM, 네트워크, ...)
. SET STATISTICS PROFILE ON
. SET STATISTICS XML ON
. SET SHOWPLAN_XML ON
. 물리적(논리적) 연산자 : 논리적 연산자 --> (내부 조인), (Aggregate), ...
. 논리적 연산자는 최종 적용된 연산자 정보 표시
. "예상" 비용 : 좋은 쿼리 나쁜 쿼리라는 판단하는 것은 문제가 있다. 성능과는 무관하다.
. 예상 행 수가 다르면 예상 비용도 다르게 된다.
*** 실행 계획 (튜닝) ***
. 실제 행 수 <--> 예상 행 수 : 차이가 적어야 한다 (OLTP or OLAP 선택 조건)
- 복합 인덱스 튜닝 부족
- 열 통계 관련 문제
- SARG 위반 등의 SQL 쿼리 자체 문제
- 기타
. (예) IO 용량 = 논리적 일기 수 6 * 8K
. 쿼리 옵티마이저가 사용하는 내부 임시 테이블 : Worktable, Workfile (사용되지 않도록 해야 함)
. RID Lookup + Join (** 중요)
. 실제 읽기 --> 논리적 읽기로 생각하면 됨
. 인덱스 쓰는 손익분기 점 기준은 1% 내외 (예) 1.325% 이하 (고정 아님)
(Table Scan (Index Scan) --> Index Seek (Lookup))
. 클러스터 인덱스 컬럼의 필드 업데이트 할 경우 insert, delete 함께 발생
. 클러스터 인덱스 선택 기준 - 트랜잭션 성능을 위한 후보 열 (OLTP성 테이블의 열)
- 등록, 수정, 삭제 등의 작업을 빠르게 하는 작업
. 주문일자
. 주문일자 + 순번
. Covering Index (Key Lookup이 발생하지 않는 경우)
. 넌클러스터 인덱스 생성 할 경우 (넌클러스터 인덱스 , 클러스터 인덱스 로 생성된다)
(UnitPrice --> UnitPrice, OrderID, ProductID)
. Key Lookup + Join (넌클러스터 인덱스의 성능을 좌우한다)
. Index 또한 테이블이다 (일반 테이블의 종속 데이블이 된다)
. Index에 필요한 필드가 포함되면 Key Lookup이 발생하지 않는다.
. key columns : 정렬 대상
. non-key columns : 정렬 대상 아님, 필더링 대상 아님 : INCLUDE (non-key column1, ...)
- 단순 Select만 하는 필드
. WHERE : 첫번째 = 조건이 오도록
. WHERE 사업장 LIKE @a --> 사업장 = @a or 사업장 in (@a)
. 조건자
. Seek 조건자 : 필드명이 보여야 한다
. select + update : 인덱스 적용된다.
. select + delete : 인덱스 적용된다.
