책뿌수기 - SQL 레벨업 8

8장. SQL의 순서 - 깨어나는 절차 지향 sql은 관계 모델의 이론에 기초하고 있기 때문에 순번을 다루기 위한 기능이 없다. 하지만 레코드에 순번을 붙여 처리하는 경우가 많아 관련기능(시퀀스 객체, ID 필드, 윈도우 함수)을 추가하고 있다. 23강. 레코드에 순번 붙이기 1. 기본키가 한 개의 필드일 경우 1) 윈도우 함수로 사용 ROW_NUMBER 함수를 사용 1 2 3 SELECT student_id, ROW_NUMBER() OVER (ORDER BY student_id) AS Seq FROM Weights; 2) 상관 서브쿼리 사용 1 2 3 4 5 SELECT student_id, (SELECT COUNT(*) FROM Weight W2 WHERE W2.student_id <= W1.student_id) AS Seq FROM Weights W1; 기능은 동일하지만 1) 방법의 성능이 좋다. 스캔 횟수 1):1회, 2):2회 2. 기본 키가 여러 개의 필드로 구성되는 경우 1) 윈도우 함수를 사용 1 2 3 SELECT class, student_id, ROW_NUMBER() OVER (ORBER BY class, stduent_id) AS Seq FROM Weight2; 2) 상관 서브쿼리를 사용 다중 필드 비교하기(문자, 숫자, 3개 비교도 가능) 1 2 3 4 5 6 SELECT class, student_id, (SELECT COUNT(*) FROM Weight W2 WHERE (W2.class, W2.student_id) <= (W1.class, W1.stduent_id) AS Seq FROM Weight W1; 3. 그룹마다 순번을 붙이는 경우 1) 윈도우 함수를 사용 class 필드에 PARTITION BY 적용 1 2 3 SELECT class, student_id, ROW_NUMBER() OVER(PARTITION BY class ORDER BY student_id) AS Seq FROM Weight2; 2) 상관서브쿼리를 사용 1 2 3 4 5 6 SELECT class, student_id, (SELECT COUNT(*) FROM COUNT(*) WHERE W2.class = W1.class AND W2.student_id <= W1.student_id) AS Seq FROM Weight2 W1; 4. 순번과 갱신 1) 윈도우 함수를 사용 셀렉트 쿼리를 SET에 넣으면 됨 1 2 3 4 5 6 7 8 UPDATE Weights3 SET Seq = (SELECT Seq FROM (SELECT class, student_id, ROW_NUMBER() OVER (PARTITION BY class ORDER BY student_id) AS Seq FROM Weights3) SeqTbl WHERE Weights3.class = SeqTbls.class AND Weights3.student_id = SeqTbl.student_id) 2) 상관 서브쿼리를 사용 1 2 3 4 5 UPDATE Weight3 SET seq = (SELECT COUNT(*) FROM Weight3 W2 WHERE W2.class = Weights3.class AND W2.student_id <= Weight3.student_id) 24강. 레코드에 순번 붙이기 응용 1. 중앙값 구하기 1) 집합 지향적 방법 1 2 3 4 5 6 7 8 SELECT AVG(weight) FROM (SELECT W1.weight FROM Weights W1, Weights W2 GROUP BY W1.weight HAVING SUM(CASE WHEN W2.weight >= W1.weight THEN 1 ELSE 0 END) >= COUNT(*)/2 AND SUM(CASE WHEN W2.weight <= W1.weight THEN 1 ELSE 0 END) >= COUNT(*)/2) TMP; 코드가 복잡하다 성능이 나쁘다. w1과 w2간에 결합이 발생 2) 절차 지향적 방법 1 - 세계의 중심을 향해 sql에서 자연수의 특징을 활용하면 ‘양쪽 끝부터 숫자 세기’를 할 수 있다 1 2 3 4 5 6 SELECT AVG(weight) AS median FROM (SELECT weight, ROW_NUMBER() OVER (ORDER BY weight ASC, student_id ASC) AS hi, ROW_NUMBER() OVER (ORDER BY weight DESC, student_id DESC) AS lo FROM Weights) TMP WEHRE hi IN(lo, lo+1, lo+2); RANK 또는 DENSE_RANK를 사용해서는 안된다. 순위가 겹치거나 빌 수 있다. 테이블 접근 1회로 감소, 대신 정렬이 2회로 늘었다. ROW_NUMBER에서 사용하는 정렬이 오름/내림차순 2개라서 그렇다. 3) 절차 지향적 방법 2 - 2빼기 1은 1 성능적으로 개선하기 1 2 3 4 5 6 SELECT AVG(weight) FROM (SELECT weight, 2 * ROW_NUMBER() OVER(ORDER BY weight) - COUNT(*) OVER() AS diff FROM Weights) TMP WHERE diff BETWEEN 0 AND 2; 정렬리 1회로 줄어든다. 이 방법이 SQL 표준으로 중앙값을 구하는 가장 빠른 방법이다. 2. 순번을 사용한 테이블 분할 비어있는 자리 출력하기 1) 집합 지향적 방법 - 집합의 경계선 1 2 3 4 5 6 7 SELECT (N1.num + 1) AS gap_start, '~', (MIN(N2.min - 1) AS gap_end FROM Number N1 INNER JOIN Numbers N2 ON N2.num > N1.num GROUP BY N1.num HAVING (N1.num + 1) < MIN(N2.num); 코드도 간단하며 집합 지향적인 방식이라 좋다. 다만, 자기 결합을 사용해야 한다(Nested Loop). 2) 절차 지향적 방법 - 다음 레코드와 비교 컨셉 : 현재 레코드와 다음 레코드를 비교해 차이가 1이 아니면 1 2 3 4 5 6 7 8 9 10 SELECT NUM+1 AS gap_start, '~', (num + diff - 1) As gap_end FROM (SELECT num, MAX(num) OVER(ORDER BY num ROWS BETWEEN 1 FOLLOWING AND 1 FOLLOWING) - num FROM numbers) TMP (num, diff) WHERE diff <> 1 테이블 접근 1회, 정렬 1회로 안정적 성능 3. 테이블에 존재하는 시퀀스 찾기 친구 또는 가족 인원수에 맞게 자리를 예약하는 경우 활용됨 1) 집합 지향적 방법 - 다시, 집합의 경계선 1 2 3 4 5 6 7 8 9 SELECT MIN(NUM) AS low, '~', MAX(num) AS high FROM (SELECT N1.num, COUNT(N2.num) - N1.num FROM Numbers N1 INNER JOIN Numbers N2 ON N2.num <= N1.num GROUP BY N1.num) N(num, gp) GROUP BY gp; 2) 집합 지향적 방법 - 다시, 다음 레코드 하나와 비교 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 SELECT low, high FROM(SELECT low, CASE WHEN high IS NULL THEN MIN(high) OVER (ORDER BY seq ROW BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING) ELSE high END AS high FROM (SELECT CASE WHEN COALESCE(prev_diff, 0) <> 1 THEN num ELSE NULL END AS low, CASE WHEN COALESCE(next_diff, 0) <> 1 THEN num ELSE NULL END As high, seq FROM (SELECT num, MAX(num) OVER(ORDER BY num ROWS BETWEEN 1 FOLLOWING AND 1 FOLLOWING) - num AS next_diff, num - MAX(num) OVER(ORDER BY num ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING) AS prev_diff, ROW_NUMBER() OVER (ORDER BY num) AS seq FROM Numbers) TMP1 ) TMP2 ) TMP3 WHERE low IS NOT NULL; 25강. 시퀀스 객체, IDENTIFY 필드, 채번 테이블 표준 SQL에는 순번을 다루는 기능으로 시퀀셜 객체나 IDENTIFY 필드가 존재한다. 하지만 사용하는 것을 권장하지는 않고, 사용한다면 시퀀스 객체를 권한다. 1. 시퀀스 객체 테이블 또는 뷰처럼 스키마 내부에 존재하는 객체 중 하나 1 2 3 4 5 6 CREATE SEQUENCE testseq START WITH 1 INCREMENT BY 1 MAXVALUE 10000 MINVALUE 1 CYCLE; INSERT 구문에서 흔히 사용된다. 1) 시퀀스 객체의 문제점 표준화가 늦어서, 구현에 따라 구문이 달라 이식성이 없고, 사용할 수 없는 구현도 있다 시스템에서 자동으로 생성되는 값이므로 실제 엔티티 속성이 아니다. 성능적인 문제를 일으킨다 2) 시퀀스 객체로 발생하는 성능 문제 순서성(순번의 대소 관계가 유지됨), 유일성, 연속성 사용자 A가 시퀀스 객체에서 NEXT VALUE를 검색할 때의 처리 시퀀스 기개체에 배타 락을 적용 NEXT VALUEfmf rjator CURRENT VALUE를 1만큼 증가 시퀀스 객체에 배타 락을 해제 3) 시퀀스 객체로 발생하는 성능 문제의 대처 (1) CACHE 읽어들일 변수를 메모리에 설정하는 것, 다만 시스템 장애시 정상동작을 담보할 수 없다. (1) NOORDER 순서성을 담보하지 않음으로써 오버 헤드를 줄인다. 4) 순번을 키로 사용할 때의 성능 문제 Hot spot 과 관련된 문제임 DBMS는 비슷한 데이털르 연속적으로 INSERT하면 물리적으로 같은 영역에 저장한다. 이 때 특정 물리적 블록에만 I/O 부하가 커지므로 성능 악화가 발생 = Hot spot, Hot block 시퀀스 객체를 사용해 INSERT를 반복하는 경우 발생하고, 대처가 불가능 5) 순번을 키로 사용할 때의 성능 문제에 대처 (1) Oracle의 열 키 인덱스 연속된 값을 도입하는 경우라도 DBMS 내부에서 변화를 주어 제대로 분산할 수 있는 구조를 사용하는 것, 다만 SELECT 성능이 나빠질 수 있다. (2) 인덱스에 복잡한 필드를 추가해서 데이터의 분산도를 높인다. 논리적으로 좋은 설계가 아님 2. IDENTIFY 필드 ‘자동 순번 필드’라고도 한다. 테이블의 필드로 정의하고, INSERT 발생할때마다 자동을 순번을 붙여주는 기능이다. 시퀀스 객체에 비해 단점이 많다. 시퀀스 객체는 여러 테이블에서 사용가능하지만, IDENTIFY 필드는 특정 테이블에 국한된다. CACHE, NOORDER를 지정할 수도 없다. 이점이 거의 없다. 3. 채번 테이블 순번을 부여하기 위해 어플리케이션에서 채번 테이블이라는 것을 만들어 사용했었다. 구시대 유물이며 문제가 안생기기를 바라는 것이 최선(튜닝할 방법도 없다)

5월 28, 2019 · Jaejin Jang

블로그 리뉴얼 사항

겉으로 보기에 바뀐것은 없어 보이지만 내부적으로 몇가지를 수정했습니다. 1. 빌드 및 deploy 자동화 현재까지 블로그에 새로운 글을 올리기 위한 과정을 다음과 같았습니다. 새로운 포스트를 추가한다. 빌드 한다. 블로그 github에 푸쉬한다. 이 중에서 23번 과정을 자동화 시켰습니다. 새로운 포스트를 추가하고 빌드용 repository에 push하기만 하면 빌드가 되고 블로그용 repository에 push가 되게 수정되었습니다. 이 과정에서 Travis CI 라는 사이트를 이용했습니다. 제일 고생한게 trivis ci에서 어떻게 빌드할지에 대한 스크립트인 .travis.yml 에서 hugo 설치였습니다. 구글에서 검색한 스크립트를 써도 잘안되더라고요. go get github 뭐 이렇게 시작하는 스크립트들이 많아서 따라해봤는데 저는 잘안됐습니다. 그래서 그냥 wget으로 dep받아서 설치하게 작성했습니다. 단순하지만 가장 확실한 방법! ...

5월 28, 2019 · Jaejin Jang

Travis CI 테스트

자동으로 빌드되어 올라가는지 테스트

5월 27, 2019 · Jaejin Jang

오랜만의 근황~ 19년 3월

오랜만의 근황이네요. 요즘에 회사에 일도 많고, 고민도 많아요. 선택이란게 참 쉬운게 아닌거 같아요. 머리아프지만 잘 해결해 나가려고 노력중이에요. 업무외에도 공부는 계속하고 있는데, 요약한걸 타이핑해서 올리는 것도 일이라 요즘 못올리고 있네요. 시간날 때 몰아서 올려야겠어요 ...

3월 5, 2019 · Jaejin Jang

책뿌수기 - SQL 레벨업 7

최근 sql 튜닝에 대해서 책도 보고 유투브에서 동영상도 몇편 봤었는데 그 중에서 저에게 가장 큰 통찰?을 줬던 영상이 있어서 링크 올립니다 [SQL Unplugged 2013] 쉽고 재미있는 인덱스 이야기/ 씨퀄로 이장래 ...

2월 7, 2019 · Jaejin Jang

책뿌수기 - SQL 레벨업 6

6. 결합(결합을 지배하는 자가 SQL을 지배한다) ch 18. 기능적인 관점으로 구분하는 결합의 종류 크로스 결합 내부 결합 외부 결합 자기 결합 등가 결합/비등가 결합 자연 결합 위에서 3개는 배타적 결합이다. 컬럼) 자연 결합 구문 자연결합 = 내부 결합 + 등가 결합 1) 크로스 결합 - 모든 결합의 모체 데카르트 곱 (1) 실무에서 사용하지 않음 그런 결과가 필요없다 비용이 크다 (2) 실수로 사용한 크로스 결합 SELECT * FROM Employees, Departments; 2) 내부 결합 - 왜 ‘내부’라는 말을 사용할까? (1) 내부 결합의 작용 크로스 결합 결과의 부분집합 (2) 내부 결합과 같은 기능을 하는 상관 서브쿼리 스칼라 서브쿼리 = 리턴값이 하나인쿼리(SELECT의 필요 조건) 상관 서브쿼리보다 결합이 우수하다 3) 외부 결합 - 왜 ‘외부’라는 말을 사용할까? (1) 외부 결합의 작동 왼쪽/오른쪽/완전 외부 결합 키를 모두 가진 레이아웃의 리포트를 만들때 사용 4) 외부 결합과 내부 결합의 차이 외부 결합은 NULL을 생성한다 5) 자기 결합 - ‘자기’란 누구일까? ch 19. 결합 알고리즘과 성능 Nested Loops Hash Sort Merge 1) Nested Loops 이중 반복 바깥 반복 테이블(구동 테이블, 외부 테이블) <-> 내부 테이블 접근하는 레코드 수 R(A) * R(B)이며 실행 시간은 레코드수에 비례한다. 구동 테이블을 작게 만드는 것이 중요하다 (1) 구동 테이블의 중요성 (내부 테이블의 결합키 필드에 인덱스가 존재) 구동 테이블을 작게 내부 테이블의 반복을 줄일 수 있음 이상적으로 구동 테이블의 레코드 한개에 내부 테이블의 레코드 한개가 대응하고, 해당 레코드를 내부 테이블의 인덱스로 사용해 찾을 수 있는 경우 레코드 레코드 수는 R(A) * 2 (2) Nested Loops 의 단점 결합키로 내부 테이블에 접근할 때 히트되는 레코드가 너무 많기 때문이다. 해결 역설적이게 구동 테이블을 큰것으로 Hash 2) Hash (1) Hash의 작동 작은 테이블을 스캔해 결합키 Hash (워키 메모리 사용량을 줄이기 위해) 큰 테이블에 접근해 Hash하고 매칭 (2) Hash의 특징 결합 테이블로부터 해시 테이블을 만드므로 Nested Loops에 비해 메모리를 많이 사용 메모리가 부족하면 저장소 사용으로 지연 출력되는 해시값은 입력값의 순서를 알지 못하므로, 등치 결합에만 사용 가능 (3) Hash가 유용한 경우 Nested Loops에서 적절한 구동 테이블이 존재하지 않는 경우 적절한 구동 테이블이 있지만, 내부 테이블에서 히트되는 레코드 수가 많은 경우 Nested Loops의 내부 테이블에 인덱스가 존재하지 않는 경우 (4) 유의사항 OLTP에서는 사용하면 안된다. 풀스캔(해시를 위해)의 비용도 고려할 것 3) Sort Merge (1) Sort Merge의 작동 결합키로 테이블들을 정렬하고, 일치하는 것 끼리 결합 대상 테이블을 모두 정렬해야하므로 메모리가 많이 사용 Hash와 달리 부등호를 사용해 결합 가능 테이블이 정렬되어 있다면 정렬을 생략 가능 테이블을 정렬하므로 테이블을 모두 스캔한 시점에 결합 완료 (2) Sort Meger가 유효한 경우 테이블 정렬을 생략 가능한 경우 4) 의도하지 않은 크로스 결합 삼각 결합 : 결합 조건이 A-B, A-C인 경우 B-C 사이에 크로스 결합이 일어날 수 있다. 옵티마이저가 B,C의 크기가 충분히 작다고 판단하는 경우 (1) 의도하지 않은 크로스 결합을 회피하는 방법 불필요한 결합 조건 추가 ch 20. 결합이 느리다면

1월 31, 2019 · Jaejin Jang

책뿌수기 - SQL 레벨업 7

7. 서브쿼리(곤란한 부분은 분할해야만 할까?) ch 21. 서브쿼리가 일으키는 폐해 1) 서브쿼리의 문제점 성능적 문제는 서브쿼리가 실체적인 데이터를 저장하고 있지 않다는 것에 있다. (1) 연산 비용 추가 서브쿼리 = SELECT 이므로 실행할때마다 SELECT 하는 것 (2) 데이터 I/O 비용 발생 연살결과가 커 저장소를 쓰게 되는 경우 급격한 속도 저하 발생 (3) 최적화를 받을 수 없음 서브쿼리의 결과에는 메타 정보가 없어 최적화가 불가능 2) 서브쿼리 의존증 (1) 서브쿼리를 사용한 방법 코드가 복잡해 읽기 어렵다 성능 결과가 일시적인 영역에 확보되므로 오버헤드 발생 최적화 불가 결합을 필요로 하기 때문에 비용이 높고 실행계획 변동 리스크가 존재 recipts 테이블 두번 스캔 필요 (2) 상관 서브쿼리는 답이 될 수 없다 어쨋든 테이블에 2번 접근해야 한다 (3) 윈도우 함수로 결합 해결 목표는 테이블 접근 1회로 줄이기 ROW_NUMBER를 사용해 구매 이력 번호를 붙이고, 이력이 1인 레코드 추출 3) 장기적인 관점에서의 리스크 관리 결합을 사용한 쿼리의 불안정 요소(상관 서브쿼리도 유사) 결합 알고리즘의 변동 리스크 환경 요인에 의한 지연 리스크(인덱스, 메모리, 매개변수 등) (1) 알고리즘 변동리스크 상황에 따라 변하는 결합 알고리즘 (2) 환경 요인에 의한 지연 리스크 결합을 사용한다는 것 = 장기적인 관점에서의 리스크 증가 4) 서브쿼리 의존증 - 응용편 (1) 다시 서브쿼리 의존증 (5) 서브쿼리는 정말 나쁠까? 생각하기는 쉬우나 RDB와는 맞지 않다 ch 22. 서브쿼리 사용이 더 나은 경우 결합쿼리는 최대한 결합 대상 레코드수를 줄이는 것이 중요한데, 옵티마이저가 잘 판단하지 못하는 경우 직접 연산 순서를 명시하는 용도로 힌트 사용 1) 결합과 집약 순서 (1) 두 가지 방법 결합 -> 집약 집약 -> 결합 (2) 결합 대상의 레코드 수 2의 경우 레코드수가 줄기 때문에 더 나은 선택일 수 있다(사전에 결합 레코드수 압축)

1월 31, 2019 · Jaejin Jang

책뿌수기 - SQL 레벨업 5

인용하는 그림은 다양한 곳에서 가져왔음을 밝힙니다 5. 반복된(절차 지향형의 속박) ch 14. 반복문 의존증 RDB는 관계 전체를 조작의 대상으로 삼기 때문에 설계상에서 반복을 제외했다 ch 15. 반복계의 공포 record at a time 사고 방식 반복계의 장점은 생각하기 쉽고 단순하다는 것 1) 반복계의 단점 성능 (1) SQL 실행의 오버헤드 전처리 a. sql 구문을 네트워크로 전송 b. DB 연결 c. sql 구문 파스 d. sql 구문의 실행 계획 생성 또는 평가 후처리 e. 결과 집합을 네트워크로 전송 a, e는 동일한 본체에 있거나 분리되어 있어도 고만고만함 b는 요즘에 커넥션 풀이라는 기술로 오버헤드를 감소시킴 c와 d가 주된 오버헤드이다. 그중에서도 c가 성가시다 c는 db가 sql을 받을때 마다 실행하므로 반복계에서는 오버헤드의 비중이 커진다 (2) 병렬 분산이 힘들다 반본계는 하나씩만 처리하기 때문에 병렬처리가 힘들다 저장소의 분산 효율이 낮다(하나씩 처리하다보니 한번에 처리하는 데이터가 얼마안됨) (3) 데이터 베이스의 진화로 인한 혜택을 받을 수 없다 대규모의 데이터를 효율적으로 다루기 위해 진화하고 있으나, 반복계를 사요하면 그 혜택을 받을 수 없다 포장계 sql이 반복계에 비해 복잡하므로 튜닝을 잘해야 하는 단점도 있는 반면 제대로만 튜닝하면 현격한 성능차이가 발생한다 반복계는 단순해 튜닝포인트도 적다 2) 반복계를 빠르게 만드는 방법은 없다 (1) 반복계를 포장계로 다시 작성 애플리케이션의 수정을 의미 (2) 각각의 sql을 빠르게 수정 너무 단순해 튜닝한 건덕지가 없음 (3) 다중화 처리 리소스 여유가 있고, 처리를 나눌 수 있는 키가 있고, 순서가 중요하지 않다면 다중화 가능 3) 반복계의 장점 sql이 단순하다 (1) 실행 계획의 안정성 실행계획이 바뀌어 느려지는 경우가 없다 (2) 예상 처리 시간의 정밀도 (3) 트랜잭션 제어가 편리 ch 16. sql에서는 반복을 어떻게 표현할까? 1) 포인트는 CASE식과 윈도우 함수 1 2 3 4 5 6 7 8 9 10 11 12 INSERT INTO Sales2 SELECT company, year, sale, CASE SIGN(sale - max(sale) OVER(PARTITION BY company ORDER BY year ROWS BETWEEN 1 PRECENDING AND 1 PRECENDING) WHEN 0 THEN '=' WHEN 1 THEN '+' WHEN -1 THEN '-' ELSE NULL END AS Var FROM Sales; 1 ROWS BETWEEN 1 PRECENDING AND 1 PRECENDING 현재 레코드에서 1개 이전부터 1개 이전까지의 레코드 범위 지정 ...

1월 30, 2019 · Jaejin Jang

책뿌수기 - SQL 레벨업 4

4. 집약과 자르기 ch 12. 집약 COUNT, SUM, AVG, MAX, MIN(Aggregate function) 1) 여러 개의 리코드를 한 개의 레코드로 집합 필드 수가 다르면 UNION 적용이 불가능하다. 또한 UNION으로 여러개의 쿼리를 머지하는 것은 성능적으로 안티패턴이다. GROUP BY 구로 집약을 했을 때 SELECT 구에 입력할 수 있는 것은 상수 GROUP BY 구에서 사용한 집약 키 집약함수 집약함수가 적용되면 여러 요소가 있는 집합으로부터 연산결과가 나옴 집약, 해시, 정렬 집약시에는 해쉬 알고리즘을 사용한다(때로는 정렬) GROUP BY 구에 지정된 필드를 해쉬 함수로 사용해 결과를 만들고, 같은 결과로 그룹을 만들어 집약한다. 고전적인 방법보다 효율적 해쉬와 정렬 모두 메모미를 많이 사용하기 때문에, 충분한 워킹 메모리가 확보되지 않으면 스왑이 발생한다(극단적 성능저하 발생) 2) 합쳐서 하나 문제 : 연령대 별로 가격이 다른 제품중에서 0 ~ 100세가 이용가능한 제품 고르기 hint : 각 범위의 상수를 합해 101인 제품 선택하기 1 2 3 4 SELECT product_id FROM PriceByAge GROUP BY product_id HAVING SUM(high_age - low_age + 1) = 101; ch 13. 자르기 집약 이외에도 중요한 자르기 라는 기능이 있다 1) 자르기와 파티션 1 2 3 4 SELECT SUBSTRING(name, 1, 1) AS label, COUNT(*) FROM Persons GROUP BY SUBSTRING(name, 1, 1); GROUP BY 구로 잘라 만든 하나 하나의 부분 집합을 ‘파티션’이라고 한다. ...

1월 29, 2019 · Jaejin Jang

책뿌수기 - SQL 레벨업 3

3. SQL의 조건 분기 ch 8. UNION을 사용한 쓸데없이 긴 표현 UNION을 사용한 조건 분기는 좋지 않다. UNION은 내부적으로 여러개의 SELECT 구문을 실행하는 실행계획으로 해석된다 (= 테이블에 접근하는 횟수(I/O)가 늘어난다) 1) UNION을 사용한 조건 분기와 관련된 간단한 예제 UNION을 사용한 조건 분기 1 2 3 4 5 6 7 SELECT item_name, year, price_tax_ex AS price FROM Items WHERE year <= 2001 UNION ALL SELECT item_name, year, price_tax_in AS price FROM Items WHERE year >= 2002 단점 : 1. 길다, 2. 테이블에 2회 접근한다. 2) WHERE 구에서 조건 분기를 하는 사람을 초보자 1 2 3 4 SELECT item_name, year CASE WHEN year <= 2001 TEHN price_tax_ex WHEN year >= 2002 THEN price_tax_in END AS price FROM Items 3) SELECT 구를 사용한 조건 분기의 실행 계획 테이블 1회 접근으로 끝난다 구문 => 식, UNION => CASE ch 9. SELECT 구를 사용한 조건 분기의 실행 계획 1) 집계 대상으로 조건 분기 UNION을 사용한 방법 1 2 3 4 5 6 7 8 9 SELECT prefecture, SUM(pop_men) AS pop_men, SUM(pop_wom) AS pop_wom FROM(SELECT prefecture, pop AS pop_men null AS pop_wom) FROM Population WHERE sex = '1' # 남성 UNION SELECT prefecture, null AS pop_men, pop AS pop_wom FROM Population WHERE sex = '2') TMP # 여성 GROUP BY prefecture 풀스캔이 2회 수행된다. ...

1월 20, 2019 · Jaejin Jang