SQL_레벨업_Do_Do

 

Intro

 

 

1장 DBMS 아키텍처

W 생각	R 생각
DB는 다양한 트레이드 오프의 균형을 잡으려는 미들웨어
성능관점 데이터의 위치 결정이 중요
DB는 갱신보다 검색에 비중을 두고 설계
SQL 실행 가능한 절차로 변환하고자 실행 계획 만듦
Quiz
DBMS의 데이터 캐시관리 위한 알고리즘	LRU(Least Recently Use)

 

2장 SQL 기초

W 생각	R 생각
SQL은 비절차형 언어, 간단하고 직관적 작성
CASE 식은 조건분기 표현 도구
쿼리는 입력과 출력을 모두 테이블에 있는 것을 기준으로 구현
집합이론 바탕 연산자 : Group by, Union, Intersect
윈도우 함수는 Group by 절에서 집약기능을 제외하고 자르는 기능만 추구
Quiz
Adress 테이블에서 성별 별로 나이 순위를 매기는 select 문??	select ,, ,,, b.rank from adress a,  adress b where a.이름 = b.이름 group by 성별 order by age desc
	select , , ,  RANK() over(partition by sex order by age desc) rnk_desc from address;

 

3장 SQL의 조건 분기

W생각	R 생각, DO
- 정확한 판단 없는 UNION 사용 지양
- select 문에서 CASE 사용, where구에서 조건분기 지양	Select , , ,  CASE WHEN col = 2020 THEN Price_ex            WHEN col = 2021 THEN Price_in END AS price
- 집계와 조건 분기
- UNION 실행 시 실행계획 풀 스캔 2회
- CASE 식 사용 시 실행계획 풀 스캔 1회	select A, , , ,  sum(CASE WHEN sex='1' THEN pop ELSE 0 END) AS POP_M sum(CASE WHEN sex='2' THEN pop ELSE 0 END) AS POP_W from tb group by A
집약결과로 조건분기
- UNION 사용한 조건분기	GROUP BY 절로 집약 후 HAVING 절로 조건 분기, UNION 결합
- CASE 식 사용	select emp_name,  CASE WHEN count(*) = 1 then MAX(team)            WHEN count(*) = 2 then '2겸직'            WHEN count(*) = 3 then '3겸직' END AS TEAM FROM E GROUP BY emp_name;
UNION을 사용하는 것이 성능적으로 좋은 경우
SQL의 성능은 저장소 IO 감소
UNION 조건 분기 표현 재검토
IN 또는 CASE 식 조건분기 표현 필요
QUIZ

 

4장 집약과 자르기

GROUP BY 구 또는 윈도우 함수의 PARTITION BY 구는 집합을 자를 때 사용
GROUP BY 구 또는 윈도우 함수는 내부적으로 해시 또는 정렬 처리를 실행
GROUP BY 구 또는 윈도우 함수와 CASE 식을 함께 사용
QUIZ
GROUP BY  연산에 정렬과 해시 중 어떤것이 쓰이는가?

 

5장 반복문

반복문 의존증
SQL은 반복문을 설계에서 제외함
반복계의 장점
반복계 성능 튜닝 가능성 없음
반복계 사용 판단 필요
QUIZ
SQL 구문 상관 서브쿼리..

 

6장 결합

결합은 SQL 성능 문제 요인
기본은 Nested Loops
배치에선 HASH
Nested Loops 효율적 동작 위해, 작은 구동 테이블과 내부테이블 인덱스 필요
결합 알고리즘이 복잡하면 실행 계획 변동 유발

 

7장 서브쿼리

서브쿼리 폐해 - 연산비용 - 데이터 IO 비용 - 최적화 받을 수 없음
서브쿼리는 복잡한 문제를 분할 편리한 도구
SQL 성능 결정 요인 IO 절대적
윈도위함수로 대체하면 성능 개선 가능성 있음
결합 대상 레코드 수를 사전에 압축해두면 성능 개선 가능

 

8장 SQL순서

	ROW_NUMBER() OVER (ORDER BY col) AS seq
SQL 절차 지향형이 윈도우 함수로 부활
윈도우 함수 사용, 가독성 향상
윈도우 함수는 결합 또는 테이블접근 줄이므로 성능향상 기대
시쿼스 객체 또는  Identity 필드는 성능 문제 원인, 주의 필요

9장 갱신과 데이터 모델

SQL 효율적으로 갱신 다중 필드 할당, 서브쿼리, CASE식, MERGE 구문
모든 문제를 코딩으로 해결 불필요
문제 해결과정에서 모델 변경 고려, 변경시 복귀 불가

 

10장 인덱스 사용

RDB 인덱스 구조	B-Tree, 비트맵( 데이터 파일을 비트 플래그로 변환, 카디널리티가 낮은 필드에 효과) , 해시 인덱스, <B+Tree 는 파일 시스템에 사용>
카티널리티와 선택률에 따라 성능결정
선택률을 제어하기 위해 UI설계 변경 필요있음
선택률이 높은 경우 인덱스 온리 스캔 활용
인덱스 사용한 성능 개선도 IO 비용 감소 노력 중 하나
QUIZ
데이터 마트 채택시 주의점 (목적: 테이블의 크기를 작게해 IO양을 줄이는 것)	데이터 최신성 데이터 마트 크기 마트 수 배치 윈도우