요즘에 깃허브 코파일럿을 파이썬에 연동해서 사용하는중인데요...
이게... 뭐랄까..
이전에 자동 완성을 완전히 뛰어 넘네요.
예를 들어, 긴 예약어나 변수를 자동완성하는게 아니고.
그다음 코드 한줄을 완전히 자동으로 만들어 버리네요.
코파일럿이 만든 코드가 맞으면 tab만 입력하면 되네요...

기존에 GPT로 코드 도움을 많이 받으면서도 놀랐는데..
이건뭐... 대화좀 하고, 상황 설명하고, 탭만 누르면 된다니.
어허... 어허.... 어허.. 뭐라 할말이 없네요..

 

 

 

 

데이터 분석을 위해서는 시각화가 중요합니다.
시각화를 통해 캐치할 부분을 비교적 쉽게 찾아낼 수 있습니다.
일한 성과를 시각화하는 것도 매우 중요한 일입니다. 또한 쉽지 않은 일이기도 하고요.
그래서 데이터 시각화, 인사이트에 대한 책들을 종종 읽어보고 있습니다.



오늘은 제가 경험했던, 선만 추가했을 뿐인데 OK가 된 리포트의 사례에 대해 정리해봤습니다.

 

이전 프로젝트에서 SQL 튜닝 프로젝트 결과를 리포팅한적이 있습니다.

열심히 몇일 동안 튜닝 후 결과를 시각화해보니, 아래와 같이 결과가 나왔습니다. 아래는 SQL별 일별 평균 실행 시간을 시각화한 차트입니다.

 

차트를 보면 일별로 SQL 평균 실행시간이 들쑥날쑥합니다.

해당 시스템은, 대량의 데이터를 처리하는 복잡한 배치가 특정 요일(월과 목)에 집중 실행되어, SQL 평균 실행시간이 요일별로 들쑥날쑥한 상황입니다. 업무를 살펴보니, 월과 목요일에 주로 제품 출하가 있으며 이때마다 시스템이 버벅되는 상황이었습니다.

빨간 세로 점선을 기준으로 왼쪽은 튜닝 반영전, 오른쪽은 튜닝 반영후입니다.
전과 후를 비교해보면, 좋아지긴 좋아졌습니다.

하지만, 여전히 배치 자체가 처리해야할 물리적인 데이터 양 때문에 개선에 한계가 있으며,

개선후에도 요일별로 SQL 평균 실행 시간이 들쑥날쑥합니다.


Tip.!

이러한 대량 데이터 배치 SQL 성능의 한계를 극복하기 위해서는 개발자와 업무 담당자의 적극적인 지원이 필요하며, 상황에 따라 배치 프로세스 전체를 변경하거나 테이블 구조 변경도 고려해야 합니다. 또한 세밀한 테스트가 필요해 튜닝 작업이 쉽지 않습니다. 대부분 사이트들이 배치 작업에 대해 튜닝을 하고 싶어하지만 현실적으로 변경에 대한 작업양과 리스크가 너무 커서 실제 바꾸지 못하는 경우가 많습니다.


 

위와 같은 튜닝 결과 차트를 실무 담당 고객에게 보여주니, 결과서를 팀장에게 보고하기에는 좀 난감해보인다고 하더군요. 자세히 보고 생각해보면 좋아진건 알겠는데, 첫 눈에 성능이 개선된걸 알 수 있어야 할거 같다고 하더군요.

제가 생각해도... 위의 차트를 이용해 고객에게 프로젝트 성과를 와닿게 하기는 쉽지 않겠다는 생각이 들더군요.

 

 

그래서.. 좀 고민을 하다가... 아래와 같이 가로선을 추가해서 고객에게 보여줬습니다.

그랬더니, 고객도.. 음.. 좋아졌네요. 고개를 끄덕거리시네요.

SQL 평균실행시간- 가로선 추가

 

 

오래전 일이지만, 소개를 한번 해보면 좋겠다 싶었던 내용입니다.
데이터 분석을 위해서는 시각화가 중요합니다.

시각화를 통해 캐치할 부분을 비교적 쉽게 찾아낼 수 있습니다.

일한 성과를 시각화하는 것도 매우 중요한 일입니다. 또한 쉽지 않은 일이기도 하고요.

그래서 데이터 시각화, 인사이트에 대한 책들을 종종 읽어보고 있습니다.

 

지금 다시 보고서를 만든다면, 아래와 같이 이동평균도 이용해볼 수 있을거 같네요. 아래는 7일간의 이동평균(오렌지색 점선)을 추가한 결과입니다.

 



[StartUP SQL]

 

StartUP SQL 소개 및 목차

SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드 전체를 블로그에 무료 오픈했습니다. (총 409장 슬라이드, 이미지로 게시) 아래 목차를 차례대로 하나씩 따라해보시기 바랍니다. 본인의

sweetquant.tistory.com

 

[StartUP Tuning]

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

 

 

 

MySQL의 IO 측정

SQL 튜닝을 위해 가장 눈여겨 볼 항목중 하나는 IO(Input, Output)입니다.

IO는 데이터를 디스크나 메모리에서 읽거나 쓰는 작업을 뜻합니다.

 

데이터베이스의 기본 기능은 데이터를 저장하는 것입니다.

데이터를 관리하기 위해 수 많은 데이터를 쉴새없이 저장(Input)합니다.

또한 데이터베이스에 저장된 데이터를 활용하기 위해, 수 없이 수 많은 데이터를 읽어올려(Output) 조회하게 됩니다.

이처럼 데이터베이스는 데이터를 읽고, 쓰는 작업을 주로 합니다. 이 과정에서 IO 횟수(데이터를 읽거나 저장한 횟수)에 따라 SQL의 성능이 달라집니다.

 

오라클이나 PostgreSQL은 SQL 실행시 발생한 IO 수치를 수집하거나 측정하는 것이 비교적 수월합니다.

반면에 MySQL은 이와 같은 IO 수치 측정이 번거롭게 되어 있습니다.

또한, 글로벌하게 측정이 되므로 여러 명이 동시에 사용 중인 DB에서는 측정이 불가능합니다.

아마도 스토리지 엔진과 DB 엔진이 나누어져 있는 아키텍쳐 때문인건 아닌지 생각해 봅니다.

 

어쨋든, MySQL도 IO를 측정할 수 있는 방법이 있으니 참고하시기 바랍니다.

MySQL에는 SHOW STATUS로 innodb_buffer_pool_read_requests를 확인해 IO 수치를 확인할 수 있습니다.

SQL 실행 전 후로 해당 수치를 측정해 두 수치의 차이를 구하면, 해당 SQL의 IO 수치가 됩니다.

(이미 말했듯이, 현재 DB를 혼자 사용하고 있어야 정확한 수치가 됩니다.)

 

아래는 특정 일자의 T_ORD_BIG 데이터를 조회하는 SQL의 IO를 측정하는 과정입니다.

현재 T_ORD_BIG에는 PK외에 인덱스가 없습니다. 그러므로 131,561이라는 높은 수치의 IO가 발생되고 있습니다.

실제 실행 시간도 5.9초 정도 걸립니다.

SHOW STATUS LIKE 'innodb_buffer_pool_read_requests'; -- 122952720

SELECT T1.CUS_ID ,COUNT(*) CNT
FROM   mytundb.T_ORD_BIG T1 
WHERE  T1.ORD_DT = STR_TO_DATE('20170103','%Y%m%d')
GROUP BY T1.CUS_ID;

SHOW STATUS LIKE 'innodb_buffer_pool_read_requests'; -- 123084281

SELECT 123084281 - 122952720 FROM DUAL; -- 131561

 

이제 아래와 같이 인덱스를 만들어 봅니다.

CREATE INDEX T_ORD_BIG_X01 ON mytundb.T_ORD_BIG(ORD_DT);

 

인덱스를 만들었으므로 앞에서 테스트한 SQL은 빨라질 것입니다. 빨라진다는 것은 IO 수치가 줄어든다는 것과 같습니다.

 

다시 IO수치를 측정해보면 다음과 같습니다.

IO 수치가 55889로 이전의 절반으로 줄어든 것을 알 수 있습니다. 실행시간 또한 감소되었습니다.

SHOW STATUS LIKE 'innodb_buffer_pool_read_requests'; -- 123220482

SELECT T1.CUS_ID ,COUNT(*) CNT
FROM   mytundb.T_ORD_BIG T1 
WHERE  T1.ORD_DT = STR_TO_DATE('20170103','%Y%m%d')
GROUP BY T1.CUS_ID;

SHOW STATUS LIKE 'innodb_buffer_pool_read_requests'; -- 123276371

SELECT 123276371 - 123220482 FROM DUAL; -- 55889

 

여러 명이 사용 중인 DB에서는 제대로 측정할 수 없는 단점과,

측정 방법이 불편한다는 단점이 있지만,

MySQL도 이와 같은 방법으로 IO를 측정할 수 있다는 점을 참고하시면 될거 같습니다.

 


[StartUP Tuning]

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

[StartUP SQL]

 

StartUP SQL 소개 및 목차

SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드 전체를 블로그에 무료 오픈했습니다. (총 409장 슬라이드, 이미지로 게시) 아래 목차를 차례대로 하나씩 따라해보시기 바랍니다. 본인의

sweetquant.tistory.com

 

 

StartUP SQL의 완전 무료 강의 노트를 오픈했습니다.(온라인 E-Book / ALL FREE ACCESS)

무료 영상 강의(자막 + 1.5배속 강추)

 

 

실습 환경 구성하기

StartUP SQL은 이론으로만 SQL을 설명하지 않습니다. 풍부한 예제를 직접 실습해볼 수 있는 환경과 직접 풀어볼 수 있는 문제를 수록하고 있습니다.

SQL 실력 향상을 위해서는, SQL을 직접 실행해보고 그에 따라 테이블의 데이터가 어떻게 데이터가 조회되는지 살펴볼 필요가 있습니다. 그리고 배운 것을 자신의 것으로 완전히 만들기 위해 그에 따른 응용 문제도 풀어볼 필요가 있습니다. 이러한 연습을 위해서는 자신의 개인 PC에 실습 환경을 구성해야 합니다.

StartUP SQL은 MySQL을 활용해 SQL을 연습합니다. MySQL은 무료 DB로서 최근에 많은 스타트업 기업들이 애용하는 DBMS입니다. 설치도 쉬우며, 사용하기도 비교적 편합니다.

 

실습 환경 구성은 다음과 같은 과정을 거칩니다.

1. 완성된 실습환경

2. MySQL 다운로드

3. MySQL 설치(Workbench라는 SQL 툴이 같이 설치됨)

4. Workbench 실행

5. Workbench 설정 변경(연습과 실습을 위해 몇 가지 설정을 바꿔 놓는 것이 좋습니다.)

6. DBeaver 설치 및 실행

7. DBeaver 설정 변경

8. 데이터베이스 IMPORT

 

 

먼저 완성된 실습 환경은 아래 그림과 같습니다.

StartUP SQL 실습 환경

 

개인 PC에 MySQL 8(윈도우즈, 맥 모두 가능)을 설치하고 startdb라는 데이터베이스를 구성합니다.

startdb는 제가 직접 만들어 공유 드리는 다양한 테이블과 데이터를 담고 있는 실습용 데이터베이스입니다. 개인적으로 이런 실습용 데이터베이스를 무료로 공개하는 것은 아쉽지만, 많은 분들이 좀 더 데이터와 SQL을 잘 배울 수 있었으면 하는 바램으로 무료로 공개하게 되었습니다.

 

MySQL 다운로드 및 설치

MySQL을 다운로드하고 설치하는 과정은 아래 글을 보시고 차분히 따라해보십시오. 생각보다 어렵지 않게 해내실 수 있을 겁니다.

https://sweetquant.tistory.com/501

 

2-1~2-3. MySQL 설치

실습환경을 준비하기 위해 MySQL을 설치합니다.실습을 하지 않는다면, SQL 실력은 전혀 늘지 않습니다.        이전 교육 슬라이드: https://sweetquant.tistory.com/500 다음 교육 슬라이드: https://swee

sweetquant.tistory.com

 

 

Workbench로 MySQL 접속해보기

MySQL을 설치한 후에는 MySQL을 설치할때 같이 설치된 Workbench라는 SQL 툴을 실행해봅니다.

Workbench라는 툴을 통해 MySQL의 데이터베이스에 접속해서 SQL을 실행할 수 있습니다. 이와 함께 Workbench의 몇 가지 옵션을 변경합니다. 그리고 DBeaver라는 툴도 추가로 설치합니다. 사실 DBeaver는 설치 안해도 상관없습니다. 하지만 최근의 많은 스타트업 기업들이 SQL 무료 툴로 DBeaver를 사용하고 있으므로 사용해보시길 권장합니다. 사실, SQL 툴은 MySQL만 지원한다면 아무거나 사용해도 상관없습니다. 다만, 이후 실습 데이터베이스 구성을 위해 DATA IMPORT 작업을 해야 하는데 이때는 Workbench를 꼭 사용해야 합니다. 지금까시 설명한 과정은 아래 글을 참고해주시면 됩니다.

https://sweetquant.tistory.com/502

 

2-4~2-5. MySQL접속해보기:Workbench와 DBeaver

데이터를 강력하게 다루는 SQL.SQL을 배우기 위한 최적의 시작점, StartUP SQL! 설치한 MySQL에 접속하기 위한 SQL 툴에 대한 설명입니다.MySQL을 설치하면 Workbench는 자동설치됩니다.Workbench만 사용해도 S

sweetquant.tistory.com

 

 

실습 데이터베이스 구성하기

마지막으로 실습용 데이터베이스를 IMPORT 할 차례입니다. 첨부로 올려드린 DUMP 파일을 다운로드 한 후에, Workbench에 접속해 DATA IMPORT 작업을 수행합니다. 과정이 복잡하지 않지만, 좀 더 이해가 쉽게 하도록 영상으로 과정을 만들어 올려드렸습니다. DUMP 파일 다운과 데이터베이스 IMPORT 과정은 아래 글을 참고해주세요.

https://sweetquant.tistory.com/503

 

2-8. 실습 데이터베이스 구성하기

실습을 위한 데이터베이스를 구성할 차례입니다.해당 과정을 진행하기 전에 MySQL 8이 설치되어 있어야 합니다. (MySQL 8.0.35 추천)아래 파일을 압축을 푼후 MySQL Workbench에서 IMPORT 작업을 해주시면

sweetquant.tistory.com

 

여기까지 완료하시면, 자신의 컴퓨터에 SQL 교육과 실습을 위한 startdb라는 멋진 데이터베이스가 만들어집니다.

이제 본격적으로 SQL을 연습을 하러 가시면 됩니다.

책 형태로 SQL을 설명드리기에는 많은 시간이 걸리므로, 우선은 교육 슬라이드를 보고 하나씩 따라해보시기 바랍니다.

 

자신이 SQL이란걸 해본적이 전혀 없다면, SELECT SQL부터: https://sweetquant.tistory.com/504

그래도 SELECT SQL은 좀 배웠다면 GROUP BY 부터: https://sweetquant.tistory.com/514

GROUP BY까지 배웠다면 JOIN 부터: https://sweetquant.tistory.com/521

JOIN까지 다 배웠다면, 분석함수만 살펴보시죠!: https://sweetquant.tistory.com/545

 

오늘 준비한 내용은 여기까지입니다. 시간 나는대로 다음 내용도 준비해보도록 하겠습니다.

감사합니다.

 


[StartUP Tuning]

SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 입문 교육

2024년 5월 주말 오프라인 교육 과정을 모집중: https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

 

 

2024년 5월 StartUP Tuning 교육의 교재 상세 목차입니다.

StartUPTuning_교재상세목차_202405.pdf
0.25MB

 

 

아래 파일은 실습에 사용할 스크립트입니다. 수강생분들께만 공유되는 자료로 압축에 암호가 설정되어 있습니다.

  - 실습 DB 구성 스크립트와 실습 스크립트, BOOSTER QUIZ 스크립트가 담겨져 있습니다.

(교육 참석 인원분들께만 현장에서 암호를 공유드릴 예정입니다.)

StartUPTuning_수강생공유자료_20240512.zip
0.21MB

 

 

감사합니다.



[StartUP Tuning]

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

[StartUP SQL]

 

StartUP SQL 소개 및 목차

SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드 전체를 블로그에 무료 오픈했습니다. (총 409장 슬라이드, 이미지로 게시) 아래 목차를 차례대로 하나씩 따라해보시기 바랍니다. 본인의

sweetquant.tistory.com

 

'SQL > StartUP Tuning' 카테고리의 다른 글

MySQL의 IO 측정  (0) 2024.05.07
최근 주문 목록 SQL 성능 개선하기  (3) 2024.05.03
INDEX 개념 잡기  (0) 2024.04.30
MySQL EXPLAIN ANALYZE #2  (0) 2024.04.29
StartUP Tuning For MySQL 24년 5월 오프라인 교육 목차  (0) 2024.04.26
MySQL EXPLAIN ANALYZE  (0) 2024.04.25
StartUP Tuning Booster Quiz Sample  (0) 2024.04.23
언제까지 인덱스를 탈 것인가?  (0) 2024.04.17

 

StartUP Tuning(MySQL): 최근 주문 목록 SQL 성능 개선하기

 
DBMS: MySQL 8.0.35
 
스타벅스 앱을 키면 Quick Order에는 최근 주문 내역을 보여줍니다.
사용자에게 앱을 키자마자 최근주문 내역을 보여줘 조금 더 편리하게 앱을 사용할 수 있도록 한 것입니다.
다른 많은 시스템이나 플랫폼도 비슷합니다. 접속을 하면, 마지막 접속기록이나 최근 구매 내역을 보여줍니다.
이와 같은 기능을 처리하는 SQL의 성능 개선 과정을 간단히 살펴보겠습니다.
 
실습을 위해 Ord(주문), OrdDet(주문상세), 상품(Item) 테이블을 사용합니다.
해당 테이블은 StartUP SQL의 무료 스크립트를 통해 자신의 환경에도 생성할 수 있습니다.
참고: https://sweetquant.tistory.com/503

 

2-8~2-10. 데이터베이스 구성하기

실습을 위한 데이터베이스를 구성할 차례입니다. 포스트 가장 아래 첨부 파일로 올린 스크립트를 사용해 실습을 위한 데이터베이스를 구성합니다. 개인적으로 피같은 스크립트이지만, 모두가 S

sweetquant.tistory.com

 
Ord와 OrdDet, Item 테이블의 ERD를 살펴보면 다음과 같습니다.

 
위 테이블들을 이용해 특정 회원의 최근 주문 상품 세 개를 가져오려고 합니다. 아래와 같이 SQL을 구현할 수 있습니다.

SELECT  T2.ItemId
        ,T3.ItemNm
        ,T1.OrdDtm
        ,T1.OrdNo
FROM    startdb.Ord T1
        INNER JOIN startdb.OrdDet T2 ON (T2.OrdNo = T1.OrdNo)
        INNER JOIN startdb.Item T3 ON (T3.ItemId = T2.ItemId)
WHERE   T1.MemberId = 'M0001'
ORDER BY T1.OrdDtm DESC
LIMIT 3;

 - Time sec: 0.018636
   * Rows read: 1263
   * Buffer pages: 3797

 
SQL의 마지막에 수행 시간과 IO(Buffer pages) 수치를 첨부했습니다. 0.018초로 그렇게 느리다고 할 수는 없는 SQL입니다. 하지만 데이터 3건만 보여주는 상황에서 3,797이란 IO 수치는 약간 높은 편입니다. 수십만 명의 회원이 동시에 사용한다고 생각해보면, 약간씩 더 느려질 소지가 있습니다.
위 SQL이 현재 시스템에서 매우 많이 사용되는 핵심 SQL이라면 당연히 추가 성능 개선이 필요합니다. SQL의 성능 개선을 위해 가장 먼저 할일은 실행계획을 확인하는 것입니다. 위 SQL의 실제 실행계획은 아래와 같습니다.

1. -> Limit: 3 row(s)  (actual time=162..162 rows=3 loops=1)
2.     -> Nested loop inner join  (actual time=162..162 rows=3 loops=1)
3.         -> Nested loop inner join (actual time=162..162 rows=3 loops=1)
4.             -> Sort: startdb.t1.OrdDtm DESC   (actual time=162..162 rows=3 loops=1)
5.                 -> Index lookup on T1 using Ord_FK01 (MemberId='M0001')  (actual time=18.5..161 rows=1257 loops=1)
6.             -> Filter: (startdb.t2.ItemId is not null)  (actual time=0.027..0.0288 rows=1 loops=3)
7.                 -> Index lookup on T2 using PRIMARY (OrdNo=startdb.t1.OrdNo)  (actual time=0.0261..0.0277 rows=1 loops=3)
7.         -> Single-row index lookup on T3 using PRIMARY (ItemId=startdb.t2.ItemId)  (actual time=0.0104..0.0105 rows=1 loops=3)

 
실행계획을 확인해 보면 세 테이블이 모두 NL(Nested Loop) 방식으로 조인되고 있습니다. 성능 개선을 위해서는 이러한 조인 방식을 이해하는 것이 매우 중요합니다. 이 부분을 여기서 다루자면 길어지므로 나중에 기회가 되면 별도로 이야기하도록 하겠습니다.
실행계획이 익숙하지 않은 분들은, 실행계획에서 문제가 되는 부분을 찾기가 쉽지 않을 것입니다.
실행계획의 마지막 단계(1번 라인)의 actual time을 보면 162..162(시작시간ms..종료시간ms)입니다. 162ms에 이 SQL이 완료되었다는 것을 알 수 있습니다.
이제, 마지막 단계를 제외하고 각 단계별로 actual time을 살펴봅니다. 가장 많은 시간을 차지하는 단계를 한 번 찾아보는거죠. 5번 단계가 다른 단계들에 비해 많은 시간을 사용하고 있는 것을 알 수 있습니다. 5번 단계의 작업 내용은 아래와 같습니다.
-> Index lookup on T1 using Ord_FK01 (MemberId='M0001')  (actual time=18.5..161 rows=1257 loops=1)
 
T1(Ord) 테이블을 Ord_FK01 인덱스를 사용해 Lookup 처리하고 있습니다. Ord_FK01은 MemberId로 구성된 인덱스입니다. 실행계획에서 actual 항목의 rows를 보면 1257입니다. Ord_FK01을 이용해 추출한 데이터가 1257건이라는 뜻입니다.
우리가 필요한건 최근 조회 세 건인데, 1257건의 주문 데이터에 접근한 것입니다. 바로 이 부분에 비효율이 있다라고 할 수 있습니다.
 
우리는 성능을 개선하기 위해 아래와 같은 인덱스를 만들어 볼 수 있습니다.
CREATE INDEX Ord_X01 ON startdb.Ord(MemberId, OrdDtm);
 
인덱스를 만든 후에 다시 같은 SQL을 실행해보고 실제 실행계획을 추출해보면 아래와 같습니다.

1. -> Limit: 3 row(s)  (actual time=0.227..0.271 rows=3 loops=1)
2.    -> Nested loop inner join   (actual time=0.226..0.269 rows=3 loops=1)
3.        -> Nested loop inner join  (actual time=0.208..0.242 rows=3 loops=1)
4.            -> Covering index lookup on T1 using Ord_X01 (MemberId='M0001') (reverse)  (actual time=0.178..0.182 rows=3 loops=1)
5.            -> Filter: (startdb.t2.ItemId is not null)  (actual time=0.0155..0.0186 rows=1 loops=3)
6.                -> Index lookup on T2 using PRIMARY (OrdNo=startdb.t1.OrdNo)  (actual time=0.0149..0.0178 rows=1 loops=3)
7.        -> Single-row index lookup on T3 using PRIMARY (ItemId=startdb.t2.ItemId)  (actual time=0.00827..0.00837 rows=1 loops=3)
        
 - Time sec: 0.005036
   * Rows read: 9
   * Buffer pages: 17
   * Disk reads: 0

 
총 실행시간이 0.005초로 인덱스를 만들기 전인 0.018초에 비해 1/3 이상으로 감소했습니다. IO 수치인 Buffer pages도 3,797에서 17로 획기적으로 감소한 것을 알 수 있습니다.
실행계획의 4번 단계를 살펴보면 다음과 같습니다.
-> Covering index lookup on T1 using Ord_X01 (MemberId='M0001') (reverse)  (actual time=0.178..0.182 rows=3 loops=1)
 
새로 만든 인덱스를 Covering Index lookp으로 처리하고 있습니다. 또한 (reverse)라고 표시되어 있는데, 이는 인덱스 리프 데이터를 역순으로 접근하는 방식을 뜻합니다. 인덱스의 리프 데이터는 인덱스 키 값으로 정렬되어 있으므로 이처럼 역순으로 접근해 세 건만 읽어들이면, 최근 주문 세건을 추출해낼 수 있습니다. 4번 단계의 rows를 보면 3으로 줄어든 것을 알 수 있습니다.
 
최근 데이터 조회에 적절한 인덱스를 만들때는 WHERE 절의 조건을 인덱스의 앞쪽 컬럼으로 배치하고 ORDER BY에 있는 컬럼을 인덱스의 뒤쪽 컬럼에 배치합니다. 그러므로 위 SQL에서 WHERE 조건인 MemberId, ORDER BY 컬럼인 OrdDtm을 조합해 Ord_X01(MemberId, OrdDtm)으로 인덱스를 구성한 것입니다. (SQL에 따라 이와 같은 인덱스 구성이 불가능하고나 복잡한 경우도 많습니다.)
 
이처럼 인덱스를 만들어주는 것만으로 최근 주문을 조회하는 SQL 성능이 획기적으로 개선되었습니다.
그런데 중요한건, "인덱스를 만들자"가 아닙니다. 실행계획을 먼저 살펴보고, 성능에 문제가 되는 지점을 찾아내는 것입니다. 그리고 그에 맞게 개선안을 적용해야 합니다. 또한 지금 살펴본 SQL보다 훨씬 복잡해서 단순 인덱스 전략으로 성능 개선을 만들어 내지 못하는 경우도 많습니다.
그러므로 우리는 성능 개선을 위해 단순히 인덱스를 만들자가 아닌, 조인의 작동원리, 인덱스의 구조와 작동원리를 잘 알고 있어야 합니다.
 
오늘 준비한 내용은 여기까지입니다. 감사합니다.


 
[StartUP Tuning]

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 
[StartUP SQL]

 

StartUP SQL 소개 및 목차

SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드 전체를 블로그에 무료 오픈했습니다. (총 409장 슬라이드, 이미지로 게시) 아래 목차를 차례대로 하나씩 따라해보시기 바랍니다. 본인의

sweetquant.tistory.com

 

 

지난 글에서 DBeaver에 GPT를 연동하는 방법을 살펴봤습니다.

https://sweetquant.tistory.com/557

 

DBeaver에 GPT 연동하기

파이참에 Copilot을 연결해서 사용하다... 음.. SQL툴에도 AI 연동이 가능할거 같은데란 생각이 들어서.찾아보니.. DBeaver에 GPT API를 연동할 수가 있네요. 준비물DBeaver(저는 24.0.3 버젼을 사용했습니다

sweetquant.tistory.com

 

간단한 SQL은 잘 작성합니다. 조금(?) 복잡한 SQL을 GPT로 시도해봤습니다.

우선, DBeaver에 연동해서 API 형태로 GPT를 사용하는 것은 실제 OpenAI에 접속해 GPT와 채팅하면서 답변을 얻는 것과는 차이가 있어 보입니다. 아무래도 GPT와 채팅하면서 얻는 답변이 좀 더 품질이 좋아보입니다.

 

테스트한 결과를 살펴보겠습니다.

먼저, 매장 테이블과 주문 테이블을 조인하는 간단한 SQL을 요청했습니다.

SQL에 성능 문제가 발생되도록 작성되었습니다. OrdDtm 컬럼을 DATE_FORMAT으로 가공해  인덱스가 있어도 사용을 못하도록 SQL이 만들어졌습니다. 그리고 아래 SQL의 프롬프트는 제 실수가 있었습니다. 사실 매장등급이란 컬럼은 없습니다. 없으면 없다고 메시지를 주면 좋은데, 그러지는 않네요. 자신이 생각할때 적절하다고 생각한 컬럼을 사용해 결과를 만들어 냅니다.

 

-- 프롬프트: 매장 테이블과 주문 테이블을 조인해서 보여줘,
-- 주문일시가 2022년 12월이고, 매장등급이 플래티넘(PLAT)인 데이터만 조회해줘
SELECT *
FROM shop s
JOIN ord o ON s.ShopId = o.ShopId
WHERE DATE_FORMAT(o.OrdDtm, '%Y%m') = '202212' AND s.ShopSt = 'PLAT';

 

이번에는 성능을 고려하라고 프롬프트를 추가하고, 매장이 아닌 회원과 조인을 요청합니다. 이번 SQL은 100점입니다. 인덱스 사용을 고려해달라고 요청하니 OrdDtm에 적절하게 조건 처리를 했습니다. 물론, OrdDtm에 인덱스는 아직 없지만요.

-- 프롬프트
-- 회원 테이블과 주문 테이블을 조인해서 보여줘, 
-- 주문일시가 2022년 12월이고, 회원등급이 플래티넘(PLAT)인 데이터만 조회해줘. 
-- 성능을 고려해서 SQL을 작성해줘. 인덱스를 사용할 수 있게 SQL을 작성해야 한다는 거지.
--  Sure, here is the SQL query that joins the `member` and `ord` tables, and filters for orders made in December 2022 by members with a 'PLAT' grade. This query is optimized for performance by using the appropriate indexes.
/*
This query joins the member and ord tables on the MemberId field.
It then filters for orders made in December 2022 and by members with a 'PLAT' grade.
The WHERE clause is written in a way that allows the use of indexes for performance optimization.
*/
SELECT m.*, o.*
FROM `member` AS m
INNER JOIN ord AS o ON m.MemberId = o.MemberId
WHERE m.MemberGd = 'PLAT'
AND o.OrdDtm >= '2022-12-01 00:00:00'
AND o.OrdDtm < '2023-01-01 00:00:00';
--  Please note that the date format and the 'PLAT' value are just examples and should be replaced with the actual format and value used in your database. Also, make sure that there are indexes on the `MemberId`, `MemberGd`, and `OrdDtm` fields for optimal performance.

 

 

 

조금 수준을 올려봅니다. StartUP SQL에서 사용하는 퀴즈를 활용해봅니다. https://sweetquant.tistory.com/542 의 마지막에 있는 16-4번 문제입니다. 그러나 여전히 성능 관점에서는 빵점 SQL이네요.

문제:
--  [BOOSTER QUIZ 16-4] 가입년도별, 회원상태별 2023년 1월의 주문 건수를 구하시오.
--  특정 가입년도별, 회원상태별 주문이 없어도 0건으로 집계해서 출력해주세요. 그리고 가입년도별 주문건수와 전체 주문건수도 추가해서 보여주세요.
--   - 대상 테이블: 회원(Member), 주문(Ord)
--   - 조회 조건: OrdDtm이 2023년 1월인 주문 데이터
--   - 조회 컬럼: JoinYear, MemberSt, OrdCnt
--   - 추가 조건:
--      : 성능을 고민하고 인덱스를 사용할 수 있도록 SQL을 작성할것.
--      : JoinYear는 JoinDtm을 년도로 변환한 값
--      : JoinYear별, MemberSt별 GROUP BY 처리하시오.
--      : OrdCnt는 JoinYear, MemberSt별 주문 건수
--      : Member와 Ord를 아우터 조인해 주문이 없는 JoinYear, MemberSt도 주문 건수가 0건으로 출력되도록 하시오.
--      : ROLLUP을 사용해 JoinYear별 중간합계와 전체합계를 추가하시오.
    
DBeaver+GPT 답변:

SELECT 
    YEAR(m.JoinDtm) AS JoinYear,
    m.MemberSt,
    COUNT(o.OrdNo) AS OrdCnt
FROM 
    `member` m
LEFT JOIN 
    ord o ON m.MemberId = o.MemberId AND YEAR(o.OrdDtm) = 2023 AND MONTH(o.OrdDtm) = 1
GROUP BY 
    YEAR(m.JoinDtm), m.MemberSt WITH ROLLUP;

 

 

조금 더 수준을 올려봅니다. 세개 테이블 조인과 분석함수까지 사용해야 하는 SQL입니다.

(문제 출처: https://sweetquant.tistory.com/548 )

휴~ 다행이네요. 아래 SQL은 에러가 발생합니다. SELECT 절에서 ItemId 컬럼을 사용할때 테이블이 지정되지 않았기 때문이죠.

--  [BOOSTER QUIZ 20-2] 2022년 11월 2022년 12월 주문에 대해, 주문년월별 상품별 주문수량을 구해주세요, 주문년월별로 주문수량에 따른 순위를 구해주세요.
--   - 대상 테이블: 주문(Ord), 주문상세(OrdDet), 상품(Item)
--   - 조회 조건: OrdDtm이 2022년 11월부터 2022년 12월 말까지인 데이터
--   - 조회 컬럼: OrdYm, ItemId, ItemNm, SumOrdQty, RankOverByYm
--   - 추가 조건:
--      : OrdYm, ItemId별 GROUP BY 처리하시오.
--      : OrdYm은 OrdDtm을 DATE_FORMAT으로 년월 형태로 변환한 값입니다.
--      : SumOrdQty는 OrdYm, ItemId별 SUM한 OrdQty 값입니다.
--      : RankOverByYm은 ItemId의 판매수량(SumOrdQty)에 대한 순위입니다. 이 순위는 년월별로 구해야 하며 판매 수량이 높으면 1이 됩니다.

SELECT 
    DATE_FORMAT(OrdDtm, '%Y%m') AS OrdYm,
    ItemId,
    ItemNm,
    SUM(OrdQty) AS SumOrdQty,
    RANK() OVER (PARTITION BY DATE_FORMAT(OrdDtm, '%Y%m') ORDER BY SUM(OrdQty) DESC) AS RankOverByYm
FROM 
    ord 
JOIN 
    orddet ON ord.OrdNo = orddet.OrdNo
JOIN 
    item ON orddet.ItemId = item.ItemId
WHERE 
    OrdDtm BETWEEN '2022-11-01' AND '2022-12-31'
GROUP BY 
    DATE_FORMAT(OrdDtm, '%Y%m'), 
    ItemId, 
    ItemNm
ORDER BY 
    OrdYm, 
    RankOverByYm;--  This query will return the total quantity of each item ordered per month for November and December 2022, along with a rank for each item based on the quantity ordered. The rank is calculated separately for each month.

 

 

DBeaver에 GPT API를 연동해 다양한 SQL을 시도해봤습니다.
아직은 API 연동으로 복잡한 SQL을 작성하는 데는 한계가 있어 보입니다.

(GPT와 직접 채팅으로 시도해보면 좀 더 결과가 잘나오지 않을까 싶네요.)
그러나 책으로만 SQL을 배운 신입보다는 낫다고도 할 수 있습니다.

지금은 AI를 활용한 SQL 작성에 한계는 있어보이지만,
개인적으로는 언젠가 이 한계를 극복할 것이라고 생각합니다.

다만, GPT가 잘할거라고 해서 우리가 공부를 게을리 해도 된다는 것은 아닙니다.
오히려 이전보다 더 깊이있게 공부할 필요가 있다고 생각합니다.
우리가 잘 알아야 잘 시킬 수 있으니까요..
언젠가는 시킬 일 조차 없게 될지도 모르지만, 그때는 그때고요.
오늘은 노력해야 하지 않을까요?

 

바짝 긴장해라. H.U.M.A.N!

 


[StartUP Tuning]
SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 입문 교육
2024년 5월 주말 오프라인 교육 과정 모집중: https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

[StartUP SQL]
데이터 분석가, 개발자, 기획자를 위한 SQL 입문 교육
교육용 슬라이드 전체 무료 오픈: https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드 전체를 블로그에 무료 오픈했습니다. (총 409장 슬라이드, 이미지로 게시) 아래 목차를 차례대로 하나씩 따라해보시기 바랍니다. 본인의

sweetquant.tistory.com

 

파이참에 Copilot을 연결해서 사용하다... 음.. SQL툴에도 AI 연동이 가능할거 같은데란 생각이 들어서.

찾아보니.. DBeaver에 GPT API를 연동할 수가 있네요.

 

준비물

DBeaver(저는 24.0.3 버젼을 사용했습니다. 아주 오래된 버젼 아니면 문제 없을거 같습니다.)

GPT 계정과 별도의 GPT API 결제 필요.(유료입니다.)

 

1. DBeaver를 실행하고 상단 메뉴 도움말(H)에서 Install New Software... 를 선택합니다.

 

2. Work with 부분에 AI를 검색해 DBeaver AI Intergration을 선택합니다.

   - 그 후 아래 목록에서 DBeaver AI Support 를 체크한 후에 다음(N) 버튼을 클릭합니다.

   - Install Details 에서도 다음으로 그냥 넘어갑니다.

 

3. 동의 및 완료를 클릭

   - 그다음 권한 관련해서는 모두 체크후 Trust 버튼 클릭

   - 권한 관련 체크가 두번 나오는데, 왠지 불안하지만 체크를 안하면 작동안할거 같아서 일단 체크하고 넘어감

   - 회사 DB에 접근하는 상황이라면 왠만하면 내용을 꼼꼼히 읽어보고 체크할 것을 권장합니다.

   - Restart로 DBeaver를 재시작합니다.

 

 

4. DBeaver가 Restart되는 동아 Openai에 가서 API키를 발급합니다.

   - API Key 같은 경우 생성할때만 확인해서 카피해놓을 수 있으며, 나중에 재확인이 불가합니다.

   - API Key 사용에 대해 미리 별도 결제가 필요합니다.

     (개인 용도로 잠깐씩 쓰는 것은 생각만큼 많이는 안나오는거 같네요. 키 발급후 키가 공개되지 않도록 주의 필요)

   - https://platform.openai.com/api-keys 접속

   - 왼쪽 api keys 선택 > 가운데  Create new secret key 클릭해서 키를 새로 생성

   - 여기서 만든 Key를 DBeaver의 AI 창에 입력해줘야 합니다. 

 

 

 

5. DBeaver를 재시작하면, SQL창 왼쪽에 GPT 마크의 버튼이 나타납니다. 해당 버튼을 클릭합니다.

   - AI 설정창이 뜨면, Service를 선택하고 API Token에 조금전에 받은 API 키를 입력후 Apply and Close를 선택합니다.

   - 현재 선택한 DB의 테이블과 컬럼에 대한 메타데이터를 AI업체에 넘겨도 되냐고 질문합니다.

   - 그래야 AI가 SQL을 작성할 수 있으니, Yes를 선택합니다.

     : 회사 DB에서 이와 같이 하시면, 아마도 안되겠죠!

 

6. 모든 준비는 끝났습니다. 이제 다시 SQL 창 왼쪽에 GPT 마크 버튼을 클릭하고, 텍스트로 SQL을 요청하면 됩니다.

 

간단한 SQL은 잘 만들어주네요.^^ 점점점 발전하겠죠. AI 무섭슴다...

 

 

준비한 내용은 여기까지입니다. 다음 글에서는 조금 더 복잡한 SQL을 시켜볼까 합니다.

테스트해본바로는, "여전히 SQL 공부는 해야 한다!"가 개인적인 결론입니다.

 


[StartUP Tuning]

  • SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 입문 교육
  • 2024년 5월 주말 오프라인 교육 과정 모집중: https://cafe.naver.com/dbian/7717
 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com


[StartUP SQL]

 

StartUP SQL 소개 및 목차

SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드 전체를 블로그에 무료 오픈했습니다. (총 409장 슬라이드, 이미지로 게시) 아래 목차를 차례대로 하나씩 따라해보시기 바랍니다. 본인의

sweetquant.tistory.com

 

본 문서는 StartUP Tuning(for MySQL) 강의의 일부를 책의 서술 형태로 정리한 문서입니다.

 

지난 글에서는 SQL 성능 문제를 인덱스로 해결했습니다. ( https://sweetquant.tistory.com/555 )

인덱스를 마스터하기 위해서는 많은 시간과 노력이 필요합니다. 인덱스를 본격적으로 공부하기에 앞서 인덱스의 개념에 대해 간단히 알아볼 필요가 있습니다.


"데이터를 정렬해 라벨링하고, 라벨을 참고해 원하는 데이터를 빠르게 찾는다"
이것이 바로 인덱스의 개념입니다.

 

INDEX 개념잡기


DBMS: MySQL 8.0.35

SQL에 성능 문제를 해결하기 위해서 가장 먼저 할 일은 실행계획을 확인하는 것입니다.

실행계획을 통해 Table scan과 같은 테이블 전체를 검색하는 작업을 발견하면, 인덱스(INDEX)를 생성해 테이블 전체 검색이 아닌 인덱스를 이용한 데이터 검색으로 SQL이 처리되도록 유도할 수 있습니다.

그러나, 이러한 단순한 사실만 알고 인덱스를 적용해서는 SQL 성능 개선을 제대로 할 수 없습니다.

실제로 인덱스를 만들어도 성능 개선 효과가 없거나 오히려 역효과가 나는 경우도 있습니다.

인덱스를 통한 성능 개선 효과가 있는지 판단하기 위해서는 인덱스의 개념과 물리적인 구조도 이해하고 있어야 합니다.


[Tip]
느린 SQL의 성능 개선 방법에는 인덱스만 있는 것은 아닙니다. 인덱스는 다양한 성능 개선 방법을 익히기 위한 시작점일 뿐입니다.


 

우리는 가장 먼저 인덱스의 개념을 이해할 필요가 있습니다. 회사에 아래 그림 좌측과 같이 12개의 거래처가 있다고 가정해봅시다. 12개의 거래처 관련된 문서를 거래처 서류함에 보관하려고 합니다.


 
회사의 팀장이 ‘나엉망’ 직원에게 거래처 서류를 정리하라고 지시했습니다.

‘나엉망’ 직원은 빨리 정리하고 쉬기 위해서 무작위로 서류를 세 개씩 나누어서 서류함의 네 개 서랍에 나누어 넣었습니다. 무작위로 서류를 서랍에 넣었으므로 결과적으로 필요한 서류가 어느 서랍에 있는지는 알 수가 없게 되었습니다. 다시 말해, Airbnb 서류가 어느 서랍에 있을지는 알 수 없습니다. Airbnb 서류를 찾기 위해서는 서류함의 서랍을 하나씩 열어봐야 합니다. 운이 좋으면 첫 번째 서랍에서 찾을 수도 있고, 운이 나쁘면 네 번째 서랍에서 서류를 발견하게 될 것입니다. 다른 거래처의 서류도 마찬가지입니다. 그날의 운에 따라 서류를 빨리 찾거나 늦게 찾거나 하는 것이죠.


이러한 상황을 알게 팀장은 이번에는 ‘나깔끔’ 직원을 불러 서류를 다시 정리하라고 지시했습니다.

‘나깔끔’직원은 모든 서류를 꺼낸 후에 알파벳 순으로 정렬을 한 후에, 알파벳 순서대로 거래처를 세 개씩 나누고 서랍에 차례대로 넣었습니다. 그리고 서랍 앞에는 어떤 알파벳으로 시작하는 거래처 서류가 있는지 알아 볼 수 있도록 라벨링을 했습니다. 다음 그림과 같이 말이죠.

 


 

이와 같이 정리를 해 놓으니, 서랍을 한 번만 열면 원하는 서류를 찾을 수 있습니다. Airbnb는 (A)로 시작하므로 1번 서랍을 열면 바로 찾을 수 있습니다. Samsung 서류는 (N)과 (T) 사이에 있으므로 3번 서랍을 열만 바로 찾을 수 있습니다.
이처럼 데이터를 정렬하고 라벨링을 해서, 원하는 데이터를 빠르게 찾을 수 있도록 도움 주는 객체가 바로 인덱스입니다.

 

인덱스는 일반적으로 삼각형 모양으로 표현합니다. 서류함을 삼각형의 위쪽 꼭지점으로, 서랍 안에 들어가 있는 서류들을 삼각형의 밑면으로 표현할 수 있습니다. 아래 그림과 같이 말이죠.

 

인덱스는 실제 B Tree 자료 구조로 구현되어 있으며 B Tree에서의 데이터 검색을 효과적으로 설명하기 위해 이와 같은 이와 같은 삼각형 모양을 자주 사용하게 됩니다.


인덱스의 개념을 간단히 살펴봤습니다. 인덱스를 제대로 사용하기 위한 첫 단추를 잠근 것입니다. 인덱스를 마스터하기 위해서는 앞으로 인덱스의 구조도 알아야 하며, SQL에 따라 인덱스 탐색이 어떻게 되는지, 그리고 인덱스의 종류도 공부해야 합니다.
인덱스 개념만 공부한 채로 섣부르게 인덱스를 만들게 되면 큰 문제를 겪을 수 있습니다.

SQL 경력이 20년이 넘는 저 역시도 여전히 인덱스를 만드는 일은 항상 걱정이 앞서는 일이기도 합니다.

인덱스는 어떤 SQL의 성능에는 도움이 되기도 하지만, 어떤 SQL의 성능에는 악영향을 줄 수도 있기 때문입니다.

항상 인덱스 추가, 변경은 긴장되는 일이랍니다.

시간을 가지고 인덱스와 SQL의 성능에 대해 더 공부해보신후 인덱스 적용을 고민해보시기 바랍니다.

 

 

PDF 다운로드

20240429_StartUPTuning_인덱스개념.pdf
0.45MB


[StartUP Tuning]

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

[StartUP SQL]

 

StartUP SQL 소개 및 목차

SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드 전체를 블로그에 무료 오픈했습니다. (총 409장 슬라이드, 이미지로 게시) 아래 목차를 차례대로 하나씩 따라해보시기 바랍니다. 본인의

sweetquant.tistory.com

 

 

글 하단 부분에서 별도 pdf로 다운로드 받으실 수 있습니다.

 

MySQL의 EXPLAIN ANALYZE 읽어보기 #2

 

DBMS: MySQL 8.0.35

지난 글에서는 MySQL의 실제 실행계획을 살펴봤습니다.

https://sweetquant.tistory.com/553

 

MySQL EXPLAIN ANALYZE

MySQL의 EXPLAIN ANALYZE 읽어보기 테스트 DBMS: MySQL 8.0.35 본 문서는 StartUP Tuning(for MySQL) 강의의 일부를 책의 서술 형태로 정리한 문서입니다. 가장 아래에 PDF 버젼으로도 첨부드리니 필요하신 분은 다

sweetquant.tistory.com

 

그리고 지난 글 마지막에 SQL의 가장 큰 문제가 어디인지 스스로 진단해보기를 부탁드렸습니다. 지난 글에서 설명한 SQL과 실행계획은 다음과 같습니다.

EXPLAIN ANALYZE
SELECT T1.CUS_ID ,COUNT(*) CNT
FROM   T_ORD_BIG T1 
WHERE  T1.ORD_DT = STR_TO_DATE('20170103','%Y%m%d')
GROUP BY T1.CUS_ID;

1 -> Table scan on <temporary>  (actual time=5992..5992 rows=9 loops=1)
2     -> Aggregate using temporary table  (actual time=5992..5992 rows=9 loops=1)
3         -> Filter: (t1.ORD_DT = ('20170103')) (actual time=35.4..5985 rows=18000 loops=1)
4             -> Table scan on T1 (actual time=0.0889..5303 rows=6.09e+6 loops=1)



라인 번호 기준으로 4->3->2->1의 흐름으로 SQL이 처리되는데, 전체 실행 시간이 5.9초 정도입니다.

이 중에 4번과 3번 라인의 Table scan과 Filter가 대부분의 실행 시간을 차지하고 있습니다.

또한, 4번 단계에서 처리한 데이터 건수가 6.09e+6(6,090,000)이었으나 3번 단계에서 18,000건으로 매우 많이 줄어 든 것을 알 수 있습니다.

이러한 정보를 종합해 보면, 4번과 3번 단계를 처리하는 과정이 성능 문제의 중심이란 것을 알 수 있습니다.

 

어디가 아픈지는 알았으니 이제 치료를 해야 하는데, 치료를 하기 위해서는 기본적인 치료법을 알고 있어야 합니다.

아픈 SQL을 치료하는 방법은 매우 다양합니다.

그 중에 Table scan(TABLE FULL SCAN)이란 질병이 있는 SQL은 인덱스(INDEX)라는 처방이 필요합니다.

이 인덱스란 치료를 처방하기 위해서는 인덱스의 구조와 인덱스를 이용해 데이터를 찾는 과정에 대한 지식이 필요합니다.

이는 별도로 길게 다루어야 할 내용입니다. 그러므로 지금은 인덱스를 만들어 효과가 있는지 정도만 살펴보도록 하겠습니다.

SQL을 보면 WHERE 절에 ORD_DT에 대한 조건이 있습니다. 그리고 실행계획의 3번 라인을 살펴보면 Filter 조건으로 ORD_DT가 사용되고 있습니다. 이는 실행계획에서 Filter 부분이 SQL의 WHERE 절을 처리한 것이라는 뜻입니다. 인덱스는 기본적으로 Filter된 컬럼에 대해 구성합니다.

아래 SQL로 인덱스를 추가합니다.

CREATE INDEX T_ORD_BIG_X01 ON T_ORD_BIG(ORD_DT);

 


[Tip]
인덱스를 만드는 작업은 DB내 자원을 제법 사용합니다. 해당 테이블에 부하가 걸리기도 합니다. 실제 인덱스를 만들어본 경험이 없으신 분은 개발 DB에서 충분한 테스트를 해보기 바랍니다. 운영 DB에서 인덱스를 만들 때는 사용자가 가장 적은 시간을 이용하는 것을 권장합니다.



인덱스를 만들고, 이전 SQL을 다시 실행해 실제 실행계획을 추출해봅니다. 아래와 같습니다.

EXPLAIN ANALYZE
SELECT T1.CUS_ID ,COUNT(*) CNT
FROM   T_ORD_BIG T1 
WHERE  T1.ORD_DT = STR_TO_DATE('20170103','%Y%m%d')
GROUP BY T1.CUS_ID;

1 -> Table scan on <temporary>  (actual time=38.2..38.2 rows=9 loops=1)
2    -> Aggregate using temporary table  (actual time=38.2..38.2 rows=9 loops=1)
3      -> Index lookup on T1 using T_ORD_BIG_X01 (ORD_DT= '20170103') (actual time=0.521..26.1 rows=18000 loops=1)

 

인덱스를 만들어준 것만으로 기존 5.9초였던 실행 시간이 0.038초로 개선되었습니다.

실행계획을 살펴보면 네 개의 단계였던 실행계획이 세 개의 단계로 줄어든 것을 알 수 있습니다.

주의 깊게 볼 것은 3번 라인의 Index Lookup입니다. 이전 실행계획에 있던 Table scan과 Filter가 사라지고 Index Lookup이 나타났습니다. Index Lookup은 WHERE 절의 동등(=) 조건에 해당하는 데이터를 인덱스를 사용해 찾아낸 경우에 나타나는 작업입니다.

Index Lookup의 actual 항목을 살펴보면 처리한 시간이 0.521..26.1ms로 매우 작습니다. 또한 인덱스로 처리한 건수(rows)가 18,000 건으로 SQL 결과를 얻어내는데 필요한 만큼의 데이터만 읽은 것입니다.

다시 말해, 불필요한 데이터에 대한 접근 없이 SQL이 처리된 것입니다.

 

이처럼 인덱스가 없는 SQL은 인덱스를 만드는 것만으로 성능 개선 효과가 나타날 수 있습니다.

물론 무조건 인덱스를 만든다고 성능 개선이 되는 것은 아닙니다. 경우에 따라서는 생성한 인덱스가 아무 효과가 없을 수도 있으며, 오히려 역효과가 날 수도 있습니다.

 

인덱스는 SQL 성능 개선을 위한 많은 방법 중에 하나입니다.

앞에서도 설명 드렸듯이 SQL의 성능 문제를 해결하기 위해 가장 먼저 할 일은 실행계획을 살펴보는 것입니다.

실행계획으로 현재 아픈 곳을 찾아내 진단하고, 현재 SQL과 테이블 구조(현재 인덱스, 컬럼 구성, 데이터 양, 테이블 간의 관계 등)를 고민해 그에 맞는 적절한 진료를 해야 합니다.


오늘 준비한 글은 여기까지입니다. 감사합니다.

 

아래는 실제 강의에서 해당 과정을 설명하는 슬라이드입니다.

 

 

 

아래는 현재 글을 pdf로 만든 자료입니다.

20240429_StartUPTuning_실행계획2.pdf
0.33MB

 

 


[StartUP Tuning]

  • SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 입문 교육
  • 2024년 5월 주말 오프라인 교육 과정을 모집중: https://cafe.naver.com/dbian/7717
 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

[StartUP SQL]

 

StartUP SQL 소개 및 목차

SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드 전체를 블로그에 무료 오픈했습니다. (총 409장 슬라이드, 이미지로 게시) 아래 목차를 차례대로 하나씩 따라해보시기 바랍니다. 본인의

sweetquant.tistory.com

 

MySQL을 활용한 SQL 튜닝 입문. StartUP Tuning의 24년 5월 교육 교재의 목차를 소개합니다.

이번에도 375장의 슬라이드로 두툼한 두께를 자랑합니다. 이 중에 BOOSTER QUIZ는 46개입니다.

교육 수강생 분들께 제본 교재를 제공해드립니다.

(제본 교재는 A4 한 페이지에 두 개의 슬라이드로 구성되어 있습니다.)

 

MySQL의 성능 개선을 위한 첫 걸음, StartUP Tuning으로 시작해보시기 바랍니다.

 - 교육 신청: https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

주목차

1. 강의 소개
2. 실습환경 구성(MySQL)
3. 실습환경 구성(Maria)
5. 성능 기본 지식
6. 실행계획
7. INDEX 1
8. INDEX 2
9. INDEX와 성능 1
10. INDEX와 성능 2
11. INDEX와 성능 3
12. ORDER BY
13. JOIN의 내부 처리 방식
14. HINT
15. JOIN과 성능
16. 맛보기 튜닝
17. Paging SQL
18. INDEX 설계
19. 성능 수집
20. 파티션
21. Transaction
22. SQL GUIDE

 

상세 목차

1. 강의 소개
    1. ERD: MYTUNDB 논리(Logical)
    1. ERD: MYTUNDB 물리(Physical)
    1. 강사 소개
    1. DBian 도서 소개
    1. StartUP Tuning
    1. 차례
2. 실습환경 구성(MySQL)
    2. 완성된 실습 환경
    2. MySQL 다운로드
    2. MySQL 다운로드: Windows MySQL 8.0.35
    2. MySQL 다운로드: MAC MySQL 8.0.35 다운로드
    2. 기존 MySQL Upgrade / Remove 선택
    2. Choosing a setup Type
    2. Check Requirements
    2. Installation
    2. Product Configuration / Type and Networking
    2. Authentication Method / Accounts and Roles
    2. Windows Service / Server File Permissions
    2. Apply Configuration
    2. MySQL Router Configuration / Connect To Server
    2. Apply Configuration
    2. Installation Complete
    2. Workbench 접속 #1
    2. Workbench 접속 #2
    2. Workbench 접속 #3
    2. Hello SQL
    2. Workbench 필요한 환경 설정 #1
    2. Workbench 필요한 환경 설정 #2
    2. Dbeaver
    2. SQL Tool
3. 실습환경 구성(Maria)
    3. 다운로드
    3. 완성된 실습 환경
    3. MariaDB 설치
    3. HeidiSQL
    3. Dbeaver
    3. Hello SQL
    4. 실습 데이터베이스 생성
    4. CREATE DATABASE
    4. 기본 데이터베이스 설정
    4. 캐릭터셋 확인
    4. 테이블 및 데이터 생성
5. 성능 기본 지식
    5. SQL 튜닝이란?
    5. SQL 성능 개선의 주요 요소
    5. 비효율 SQL이란?
    5. SQL 처리 과정
    5. Execution Plan과 Optimizer #1
    5. Execution Plan과 Optimizer #2
    5. Execution Plan과 Optimizer #3
    5. Statistics #1
    5. Statistics #2
    5. Statistics #3
    5. Storage Engine
    5. Oracle VS. MySQL
    5. IO
    5. 물리적 IO와 논리적 IO #1
    5. 물리적 IO와 논리적 IO #2
    5. Buffer pool size 변경하기
    5. SQL 성능 개선 프로세스
    5. 지속적인 SQL 성능 개선 필요성
6. 실행계획
    6. 인덱스 초기화
    6. EXPLAIN
    6. EXPLAIN 이해하기
    6. EXPLAIN 이해하기 – select_type
    6. EXPLAIN 이해하기 – 실행계획의 흐름 해석하기
    6. EXPLAIN 이해하기 – type(데이터 접근방식)
    6. EXPLAIN – Extra(옵티마이져 동작방식) 이해하기
    6. EXPLAIN FORMAT
    6. EXPLAIN FORMAT = TREE (MySQL)
    6. 실행한 SQL의 실제 접근 데이터 건수 측정
    6. 실행한 SQL의 요청 논리적IO 측정
    6. ANALYZE SQL(MariaDB)
    6. EXPLAIN ANALYZE #1 (MySQL)
    6. EXPLAIN ANALYZE #2 (MySQL)
    6. PROFILING
    6. 다른 세션의 실행계획 확인 (MySQL)
    BOOSTER QUIZ 6-1
7. INDEX 1
    7. INDEX란? 우선 읽어보자!
    7. 실행계획의 비효율을 찾아 INDEX로 해결하기 #1
    7. 실행계획의 비효율을 찾아 INDEX로 해결하기 #2
    7. 실행계획의 비효율을 찾아 INDEX로 해결하기 #3
    7. INDEX의 생성과 삭제
    7. INDEX 개념 잡기 #1
    7. INDEX 개념 잡기 #2
    7. B-Tree INDEX #1
    7. B-Tree INDEX #2
    7. 테이블 구조
    7. Heap 구조와 Table Scan(TABLE FULL SCAN)
    7. Heap과 INDEX #1
    7. Heap과 INDEX #2
    7. Heap과 INDEX #3
    7. Heap과 INDEX #4
    7. Heap과 INDEX #5
    7. 인덱스는 삼각형으로
    7. 인덱스 탐색 과정의 시각화 #1
    7. 인덱스 탐색 과정의 시각화 #2: CUS_ID 인덱스를 사용한 데이터 검색
    7. 인덱스 직접 그려보기
    7. CLUSTERED (INDEX) #1
    7. CLUSTERED (INDEX) #2
    7. CLUSTERED (INDEX) #3
    7. HEAP VS. CLUSTERED #1
    7. HEAP VS. CLUSTERED #2
8. INDEX 2
    8. 데이터 접근 방법
    8. 인덱스를 이용한 데이터 접근 #1
    8. 인덱스를 이용한 데이터 접근 #2: 인덱스 접근 시각화
    8. 인덱스를 이용한 데이터 접근 #3: INDEX LOOKUP
    8. 인덱스를 이용한 데이터 접근 #4: INDEX RANGE SCAN
    8. 인덱스를 이용한 데이터 접근 #5: COVERING INDEX (LOOKUP/RANGE SCAN)
    8. 인덱스를 이용한 데이터 접근 #6: INDEX SCAN(INDEX FULL SCAN)
    8. 인덱스를 이용한 데이터 접근 #7: 정리
    8. 테이블(클러스터드) 접근 #1
    8. 테이블(클러스터드) 접근 #2: 검색양에 따른 성능 변화
    8. 테이블(클러스터드) 접근 #3: 테이블 접근 횟수에 따른 성능 변화
    8. 테이블(클러스터드) 접근 #4: Covering Index
    8. 테이블(클러스터드) 접근 #5: 클러스터드 인덱스를 이용한 검색
    8. INDEX 확인하기 #1
    8. INDEX 확인하기 #2
    8. CLUSTERD INDEX에 대한 고민
    8. InnoDB가 제공하는 INDEX 구조
    8. INDEX 분류
    8. 조건에 따른 인덱스 선택
    BOOSTER QUIZ 8-1
    BOOSTER QUIZ 8-2
    BOOSTER QUIZ 8-3
    BOOSTER QUIZ 8-4
    BOOSTER QUIZ 8-5
9. INDEX와 성능 1
    9. 어느 컬럼에 인덱스를 만들 것인가? #1
    9. 어느 컬럼에 인덱스를 만들 것인가? #2
    9. 어느 컬럼에 인덱스를 만들 것인가? #3
    9. 어느 컬럼에 인덱스를 만들 것인가? #4: RNO를 제외한 조건은 어디서 처리되는가?
    BOOSTER QUIZ 9-1
    BOOSTER QUIZ 9-2
    BOOSTER QUIZ 9-3
    9. 공식만 외우지 말자 #1
    9. 공식만 외우지 말자 #2
10. INDEX와 성능 2
    10. 단일 인덱스 VS. 복합 인덱스 #1
    10. 단일 인덱스 VS. 복합 인덱스 #2
    10. 단일 인덱스 VS. 복합 인덱스 #3
    10. 단일 인덱스 VS. 복합 인덱스 #4
    10. 단일 인덱스 VS. 복합 인덱스 #5
    10. 단일 인덱스 VS. 복합 인덱스 #6: 오라클의 실행계획
    BOOSTER QUIZ 10-1
    10. 복합 인덱스의 컬럼 순서
    10. 복합 인덱스 컬럼 순서에 따른 성능 차이 #1
    10. 복합 인덱스 컬럼 순서에 따른 성능 차이 #2
    10. 복합 인덱스 컬럼 순서에 따른 성능 차이 #3
    10. 복합 인덱스 컬럼 순서에 따른 성능 차이 #4
    BOOSTER QUIZ 10-2
    BOOSTER QUIZ 10-3
    BOOSTER QUIZ 10-4
    10. 복합 인덱스의 선두 조건 누락
    10. 복합 인덱스 컬럼 선정과 순서 #1
    10. 복합 인덱스 컬럼 선정과 순서 #2
    10. 복합 인덱스 컬럼 선정과 순서 #4
    BOOSTER QUIZ 10-5
    BOOSTER QUIZ 10-6
    BOOSTER QUIZ 10-7
    BOOSTER QUIZ 10-8
    10. 복합 인덱스 정리
11. INDEX와 성능 3
    11. 인덱스를 제대로 활용할 수 없는 SQL #1
    11. 인덱스를 제대로 활용할 수 없는 SQL #2
    BOOSTER QUIZ 11-1
    BOOSTER QUIZ 11-2
    11. Index Covering(Covered Index) #1
    11. Index Covering(Covered Index) #2
    BOOSTER QUIZ 11-3
    11. 복합 인덱스의 선두 조건 누락 #1
    11. 복합 인덱스의 선두 조건 누락 #2
    11. 복합 인덱스의 선두 조건 누락 #3
    11. 복합 인덱스의 선두 조건 누락 #4 – Index Skip Scan
    BOOSTER QUIZ 11-4
    11. 언제까지 인덱스를 탈 것만 같아? #1
    11. 언제까지 인덱스를 탈 것만 같아? #2
    11. 언제까지 인덱스를 탈 것만 같아? #3
    11. 너무 많은 인덱스의 위험성
    11. 클러스터드 인덱스의 크기
    11. INDEX란? 한 번 더 읽어보자!
    BOOSTER QUIZ 11-5
12. ORDER BY
    12. 비효율 찾기
    12. Using filesort
    12. Using filesort 제거하기
    12. sort buffer size
    12. INDEX RANGE SCAN - ASC
    12. INDEX RANGE SCAN - DESC
    12. INDEX RANGE SCAN – 정렬과 무관하게 인덱스를 사용하면?
    12. ORDER BY LIMIT n
    12. ORDER BY SQL을 위한 인덱스 전략 #1
    12. ORDER BY SQL을 위한 인덱스 전략 #2
    12. ORDER BY SQL을 위한 인덱스 전략 #3
    BOOSTER QUIZ 12-1
    BOOSTER QUIZ 12-2
13. JOIN의 내부 처리 방식
    13. JOIN의 내부 처리 방식
    13. NL JOIN 이해하기 #1
    13. NL JOIN 이해하기 #2
    13. HASH JOIN 이해하기 #1
    13. HASH JOIN 이해하기 #2
    13. HASH JOIN 이해하기 #1 (MariaDB)
    13. HASH JOIN 이해하기 #2 (MariaDB)
    13. HASH JOIN 이해하기 #3 (MariaDB)
    13. HASH JOIN 이해하기 #4 (MariaDB)
    13. HASH JOIN 이해하기 #1 (MySQL)
    13. HASH JOIN 이해하기 #2 (MySQL)
    BOOSTER QUIZ 13-1
    BOOSTER QUIZ 13-2
14. HINT
    14. Optimizer Hints
    14. 인덱스 힌트
    14. JOIN_ORDER #1
    14. JOIN_ORDER #2
    14. JOIN_ORDER 와 JOIN 방법 제어
15. JOIN과 성능
    15. NL JOIN 튜닝 – 선행접근과 후행접근
    15. NL JOIN 튜닝 – 후행접근 조인 컬럼의 인덱스 유무 #1
    15. NL JOIN 튜닝 – 후행접근 조인 컬럼의 인덱스 유무 #2
    15. NL JOIN 튜닝 – 후행접근 조인 컬럼의 인덱스 유무 #4
    15. NL JOIN 튜닝 – 후행접근 조인 컬럼의 인덱스 유무 #4
    15. NL JOIN 튜닝 – 후행접근 조인 컬럼의 인덱스 유무 #5
    15. NL JOIN 튜닝 – 후행접근 조인 컬럼의 인덱스 유무 #6
    15. NL JOIN 튜닝 – 후행접근 조인 컬럼의 인덱스 유무 #7
    15. NL JOIN 튜닝 – join_cache_level (MariaDB)
    BOOSTER QUIZ 15-1
    BOOSTER QUIZ 15-2
    15. NL JOIN 튜닝 – 조인 순서 #1
    15. NL JOIN 튜닝 – 조인 순서 #2
    15. NL JOIN 튜닝 – 조인 순서 #3
    15. NL JOIN 튜닝 – 조인 순서 #4
    15. NL JOIN 튜닝 – 조인 순서 #5
    BOOSTER QUIZ 15-3
    15. NL JOIN 튜닝 – 여러 테이블의 조인 #1
    15. NL JOIN 튜닝 – 여러 테이블의 조인 #2
    15. NL JOIN 튜닝 – 여러 테이블의 조인 #3
    15. NL JOIN 튜닝 – 여러 테이블의 조인 #4
    15. HASH JOIN 튜닝 – Build Input 선택 #1 (MariaDB)
    15. HASH JOIN 튜닝 – Build Input 선택 #2 (MariaDB)
    15. HASH JOIN 튜닝 – Build Input 선택 #1 (MySQL)
    15. HASH JOIN 튜닝 – Build Input 선택 #2 (MySQL)
    15. HASH JOIN 튜닝 – 인덱스
    BOOSTER QUIZ 15-4
    BOOSTER QUIZ 15-5
    15. JOIN과 성능 Summary

16. 맛보기 튜닝
    16. 특정 고객의 마지막 주문 일자 구하기 #1
    16. 특정 고객의 마지막 주문 일자 구하기 #2
    16. 특정 고객의 마지막 주문 일자 구하기 #3
    BOOSTER QUIZ 16-1
    16. 여러 고객의 마지막 주문 일자: 서브쿼리 #1
    16. 여러 고객의 마지막 주문 일자: 서브쿼리 #2
    16. 불필요한 카운트
    16. Materialize #1
    16. Materialize #2: SQL 변경과 NO_MERGE
    16. Materialize #3: SQL 변경
    BOOSTER QUIZ 16-2
    16. 무리한 스칼라 서브쿼리
    BOOSTER QUIZ 16-3
    16. WHERE 절 서브쿼리의 순환조건 #1
    16. WHERE 절 서브쿼리의 순환조건 #2
    16. WHERE 절 서브쿼리의 순환조건 #3
    BOOSTER QUIZ 16-4
    16. WHERE 절 서브쿼리의 순환조건: 마지막 데이터 & 빅 테이블 #1
    16. WHERE 절 서브쿼리의 순환조건: 마지막 데이터 & 빅 테이블 #2
    BOOSTER QUIZ 16-5
    BOOSTER QUIZ 16-6
    16. QUERY TRANSFORMATION
    16. 조건 공급 #1
    16. 조건 공급 #2
    16. 조건 공급 #3
    16. 조건 공급 #4
    16. 적절하지 않은 조건 공급
    BOOSTER QUIZ 16-7
    BOOSTER QUIZ 16-8
    16. MySQL의 강력한 무기 Using index for group by #1
    16. MySQL의 강력한 무기 Using index for group by #2
    16. MySQL의 강력한 무기 Using index for group by #3
    16. MySQL의 강력한 무기 Using index for group by #4
    16. MySQL의 강력한 무기 Using index for group by #5
    BOOSTER QUIZ 16-9
    BOOSTER QUIZ 16-10
    BOOSTER QUIZ 16-11
    16. 날짜 테이블 #1
    16. 날짜 테이블 #2
    16. 날짜 테이블 #3
    BOOSTER QUIZ 16-12
    16. 값의 분포도를 생각하자 #1
    16. 값의 분포도를 고려 #2
    16. 조인을 추가한 복합 인덱스 활용 #1: 날짜 조건 누락(개선 전)
    16. 조인을 추가한 복합 인덱스 활용 #2 : 날짜 조건 누락(개선 후)
    16. 조인을 추가한 복합 인덱스 활용 #1: 회원ID 누락(개선 전)
    16. 조인을 추가한 복합 인덱스 활용 #2: 회원ID 누락(개선 후)
17. Paging SQL
    17. 페이징의 종류
    17. WAS 페이징
    17. DB 페이징 #1
    17. DB 페이징 #2
    17. DB-INDEX 페이징 #1
    17. DB-INDEX 페이징 #2
    17. DB-INDEX 페이징 #3
    17. DB-INDEX 페이징 #4
    17. 조인 SQL의 DB-INDEX 페이징 #1
    17. 조인 SQL의 DB-INDEX 페이징 #2
    17. DB-INDEX 페이징 유지의 어려움
    BOOSTER QUIZ 17-1
    BOOSTER QUIZ 17-1
18. INDEX 설계
    18. INDEX 설계
    18. INDEX 설계 과정
    BOOSTER QUIZ 18-1
19. 성능 수집
    19. SLOW Query 설정
    19. Performance Schema
    19. 성능 관련 주요 VIEW
20. 파티션
    20. 파티션 개념 #1
    20. 파티션 개념 #2
    20. 파티션 개념 #3
    20. 파티션 개념 #3
    20. 파티션 만들기
    20. 파티션 성능 #1
    20. 파티션 성능 #2
    20. 파티션 성능 #3
21. Transaction
    21. Transaction
    21. ACID
    21. Isolation level
    21. MySQL과 MariaDB의 기본 Isolation level
    21. Isolation level 변경하기
    21. AUTO COMMIT
    21. 테스트 테이블 생성
    21. WAIT 테스트 #1
    21. WAIT 테스트 #2
    21. WAIT 테스트 #3
    21. 출금 테스트 #1
    21. 출금 테스트 #2
    21. 출금 테스트 #3
    21. 출금 테스트 #4
    21. Manual Commit 과 MetadataLock
    21. Isolation Level에 따른 테스트 #1
    21. Isolation Level에 따른 테스트 #2
22. SQL GUIDE
    22. SQL GUIDE의 목적
    22. 필수 SQL GUIDE - 01
    22. 필수 SQL GUIDE - 02
    22. 필수 SQL GUIDE - 03
    22. 필수 SQL GUIDE - 04
    22. 필수 SQL GUIDE - 05
    22. 필수 SQL GUIDE - 06
    22. 필수 SQL GUIDE - 07
    22. 필수 SQL GUIDE - 08
    22. 필수 SQL GUIDE - 09
    22. 필수 SQL GUIDE - 10
    22. 필수 SQL GUIDE - 11
    22. 필수 SQL GUIDE - 12
    22. 필수 SQL GUIDE - 13
    22. 권장 SQL GUIDE - 01
    22. 권장 SQL GUIDE - 02
    22. 권장 SQL GUIDE - 03
    22. 권장 SQL GUIDE - 04
    22. 권장 SQL GUIDE - 05
    22. 권장 SQL GUIDE - 06
    22. 권장 SQL GUIDE - 07
    22. 권장 SQL GUIDE - 08
    22. 권장 SQL GUIDE - 09
    22. 권장 SQL GUIDE - 10
    22. 권장 SQL GUIDE - 11

 

 

 

 

MySQL의 EXPLAIN ANALYZE 읽어보기

 

테스트 DBMS: MySQL 8.0.35

 

본 문서는 StartUP Tuning(for MySQL) 강의의 일부를 책의 서술 형태로 정리한 문서입니다. 가장 아래에 PDF 버젼으로도 첨부드리니 필요하신 분은 다운 받아가시기 바랍니다.

 


SQL의 성능에 문제가 있을 때 우리가 가장 먼저 할 일은 실행계획을 살펴보는 것입니다. MySQL은 8버전부터 EXPLAIN ANALYZE 기능을 지원합니다. EXPLAIN ANALYZE는 “실제 실행된” SQL의 실행계획을 Tree 형태로 보여줍니다. 실제 실행계획은 SQL 성능 개선할 때 매우 유용한 기능입니다.
아래 SQL은 T_ORD_BIG 테이블에서 특정 일자의 데이터를 조회해 고객ID(CUS_ID)별 주문 건수를 구하는 SQL입니다. EXPLAIN ANALYZE를 사용했으므로 SQL의 실행 결과가 아닌 SQL을 처리한 과정에 해당하는 실행계획을 결과로 얻을 수 있습니다.

EXPLAIN ANALYZE
SELECT T1.CUS_ID ,COUNT(*) CNT
FROM   T_ORD_BIG T1 
WHERE  T1.ORD_DT = STR_TO_DATE('20170103','%Y%m%d')
GROUP BY T1.CUS_ID;

 

위 SQL을 실행하면 약 5.9초 정도의 시간이 걸리며, 아래와 같은 실제 실행계획이 출력됩니다. (지면상 실행계획의 일부 내용은 생략했습니다.)

-> Table scan on <temporary>  (actual time=5992..5992 rows=9 loops=1)
    -> Aggregate using temporary table  (actual time=5992..5992 rows=9 loops=1)
        -> Filter: (t1.ORD_DT = ('20170103')) (actual time=35.4..5985 rows=18000 loops=1)
            -> Table scan on T1 (actual time=0.0889..5303 rows=6.09e+6 loops=1)

 

Tree 형태의 실행계획은 일반적으로 가장 최하위 자식(Child) 단계부터 부모(Parent) 단계로 가면서 처리가 됩니다. 그러므로 위 실행계획의 흐름은 4->3->2->1 순서가 됩니다.

 


[Tip]
실행계획은 SQL의 내부적인 처리 흐름을 보여줄 뿐, 실제 DB 내부적인 처리 순서를 완벽하게 표현해주지는 않습니다.
4->3->2->1이란 순서가 4가 완료된 후 3이 실행되고, 3이 완료되면 2가 실행된다고 말하기는 어렵습니다.
4가 완료된 후 3이 처리되었을 수도 있으며, 4가 처리되면서 3이 동시에 처리될 수도 있습니다.
실행계획을 통해 내부적인 처리 순서를 완벽히 파악하기 보다는 전반적인 흐름을 이해하는 것에 초점을 맞추는 것이 좋습니다.


 

실행 계획의 처리 흐름대로 따라가면서 각 단계를 하나씩 살펴보도록 하겠습니다

 

4번 라인: Table scan on T1

가장 첫 번째 단계인 4번 라인을 보면, Table scan이란 작업이 실행되고 있습니다.

Table scan이란 테이블 전체를 검색하는 것을 뜻합니다. 테이블에 1억 건이 있다면 1억 건 전부를, 10억 건이 있다면 10억 건 전부를 검색했음을 뜻합니다.

Table scan 뒤에는 대상 테이블의 별칭이 적혀 있습니다.

현재 실행계획에는 Table scan on T1 이라고 표시되어 있습니다. 실행한 SQL의 FROM 절에서 T_ORD_BIG에 T1이란 별칭을 사용했습니다. 그러므로 Table scan의 대상이 T_ORD_BIG임을 알 수 있습니다.

감사하게도 실제 실행계획에는 해당 단계별로 수행된 시간과 처리한 건수의 정보를 actual 항목에 표시해 줍니다. 이와 같은 실제 처리된 정보는 SQL 튜닝에 매우 유용합니다. 4번 라인의 Table scan의 actual 정보는 다음과 같습니다.

  • Table scan on T1 (actual time=0.0889..5303 rows=6.09e+6 loops=1)

actual의 time 부분을 살펴보면 0.0859..5303로 표시되어 있습니다.

이는 해당 단계가 0.0859ms에 시작해 5303ms에 종료되었음을 뜻합니다. 5303ms는 약 5.3초입니다. 위 SQL은 총 실행 시간이 5.9초 정도가 걸립니다. 그 중에 4번 라인의 Table scan이 5.3초로 대부분을 차지하고 있는 상황입니다.

actual 항목 중에 rows 부분도 주의 깊게 살펴봐야 합니다. rows는 해당 단계가 끝났을 때 추출된 실제 데이터 건수입니다.

여기에는 6.09e+6이라고 표시되어 있습니다. 이는 과학적 표기법(또는 지수 표기법) 형태의 수치로서 구글이나 GPT를 통해 일반적인 숫자로 환산해보면 6,090,000 입니다. 다시 말해 Table scan 단계에서 추출된 데이터는 6,090,000 건입니다.

이 수치는 정확히 T_ORD_BIG의 현재 데이터 건 수와 일치합니다. Table Scan에서 테이블 전체 데이터를 읽었다는 것을 알 수 있으며, 이 과정이 5.3초 정도가 걸렸음을 알 수 있습니다.

 


3번 라인: Filter

Table scan을 거쳐 다음 실행되는 단계는 3번 라인의 Filter입니다. Filter는 특정 조건을 사용해 데이터를 걸러내는 처리를 하는 작업입니다.

MySQL의 Filter 단계에는 Filter로 사용된 조건이 같이 표시됩니다. 3번 라인의 실행계획을 통해 ORD_DT 조건에 대해 Filter가 처리된 것을 알 수 있습니다.

  • Filter: (t1.ORD_DT = ('20170103')) (actual time=35.4..5985 rows=18000 loops=1)

 

actual 항목을 보면 time 부분이 35.4..5985입니다. 35.4ms에 시작해 5985ms에 해당 단계가 완료되었습니다. 처리되는 시간대가 4번 단계의 Table scan과 겹치는 것으로 보아 3번과 4번이 동시에 처리되는 작업임을 유추할 수 있습니다. 실제로도 테이블의 데이터를 검색하면서 Filter 작업이 동시에 이루어집니다. 다만, MySQL의 Tree 실행계획에서는 별도 단계로 표시해준 것입니다. 다른 DBMS의 경우는 3번과 4번 단계를 하나의 단계로 표현해주기도 합니다.

3번 단계의 rows를 보면 18,000입니다. 4번 단계의 rows는 6,090,000이었습니다. 4번->3번 흐름으로 SQL이 처리되므로 6,090,000 건의 데이터에 접근해 결과적으로 18,000 건만 남았다고 해석할 수 있습니다. 이를 역산해보면 6,072,000 건((6,090,000-18,000)의 데이터가 4번에서 3번 단계를 거치면서 버려진 것입니다. 버려졌다는 것은 SQL 결과를 만드는데 불필요하다는 뜻입니다.

그러므로 이러한 불필요한 접근을 줄일 수 있다면 SQL 성능이 개선될 수 있습니다. 이는 다음 번에 이야기하기로 하고 계속해서 실행계획을 읽어 나가도록 하겠습니다.

 

2번 라인: Aggregate

2번 라인의 Aggregate는 데이터를 집계 처리하는 작업입니다.

  • Aggregate using temporary table  (actual time=5992..5992 rows=9 loops=1)

 

현재 우리가 실행한 SQL에는 “GROUP BY T1.CUS_ID”가 포함되어 있습니다. 그러므로 DB 내부적으로 Aggregate 작업을 거쳐 집계된(GROUP BY) 결과를 만들어냅니다. actual 항목의 time을 보면  5992..5992로 5.9초에 시작해 5.9초에 끝난 것을 알 수 있습니다. 시작과 종료 시간이 0.000초로 매우 빨리 처리된 것입니다.

Aggregate를 거쳐 만들어진 결과 건수는 9입니다. actual의 rows를 보면 알 수 있습니다. Aggregate의 결과는 9건이지만, Aggregate를 수행한 대상 건수는 몇 건일까요? 바로 이전 실행 단계인 3번 라인의 Filter의 rows에 그 정답이 있습니다. 3번 라인의 Filter의 rows는 18,000 이었습니다. 그러므로 18,000 건의 데이터가 Aggregate 작업으로 공급되었으며, 18,000 건의 데이터를 집계해 9 건의 결과를 만든 것입니다.

이처럼 rows 항목은 이전 단계와 비교해 보는 것이 좋습니다. 각 실행 단계를 거치면서 데이터 양이 어떻게 변하는지 추적할 수 있으며, 이를 통해 과도한 데이터 흐름이 있는 단계를 찾아낼 수 있습니다.


1번 라인: Table scan on <temporary>

1번 라인의 처리 내용을 살펴보면 4번 라인과 마찬가지로 Table scan을 하고 있습니다.

  • Table scan on <temporary>  (actual time=5992..5992 rows=9 loops=1)

다만 1번 라인의 Table scan 대상은 <temporary>라는 임시 테이블입니다. 이 임시 테이블은 2번 라인의 Aggregate를 거쳐 내부적으로 만들어진 테이블입니다. Aggregate 단계에서 9건의 데이터가 만들어졌으므로 <temporary>에는 당연히 9 건의 데이터만 담겨 있습니다. 9건의 데이터를 Table scan하는 작업은 매우 빠릅니다.

사실 실행 계획의 가장 마지막 단계는 SQL의 최종 결과를 단순 출력하는 단계로 대부분의 경우 주의 깊게 볼 필요는 없습니다.

 

지금까지의 내용을 기억하면서 아래 SQL과 실행계획을 다시 한번 꼼꼼하게 살펴보시기 바랍니다. 어느 부분이 현재 SQL의 가장 큰 문제인지 진단해볼 수 있을까요? 해결법은 찾지 못하더라도, 어느 부분이 가장 문제가 있다고 말할 수는 있어야 합니다.

EXPLAIN ANALYZE
SELECT T1.CUS_ID ,COUNT(*) CNT
FROM   T_ORD_BIG T1 
WHERE  T1.ORD_DT = STR_TO_DATE('20170103','%Y%m%d')
GROUP BY T1.CUS_ID;
-> Table scan on <temporary>  (actual time=5992..5992 rows=9 loops=1)
    -> Aggregate using temporary table  (actual time=5992..5992 rows=9 loops=1)
        -> Filter: (t1.ORD_DT = ('20170103')) (actual time=35.4..5985 rows=18000 loops=1)
            -> Table scan on T1 (actual time=0.0889..5303 rows=6.09e+6 loops=1)


해결법은 기회가 된다면 다음 글에 이어서 적어보도록 하겠습니다. 감사합니다.

 

아래는 지금까지의 내용을 PDF로 정리한 문서입니다.

20240424_StartUPTuning_실행계획.pdf
0.35MB

 

 

StartUP Tuning 오프라인 강의에서는 지금까지 설명한 내용을 아래와 같은 슬라이드로 설명합니다.

 

 


SQL을 완벽히 배우는 방법 StartUP SQL!

StartUP SQL의 완전 무료 강의 노트를 오픈했습니다.(온라인 E-Book / ALL FREE ACCESS)

무료 영상 강의(자막 + 1.5배속 강추)


 

[StartUP Tuning]

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

[StartUP SQL]

 

StartUP SQL 소개 및 목차

SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드 전체를 블로그에 무료 오픈했습니다. (총 409장 슬라이드, 이미지로 게시) 아래 목차를 차례대로 하나씩 따라해보시기 바랍니다. 본인의

sweetquant.tistory.com

 

이번 StartUP Tuning(MySQL을 활용한 SQL 튜닝 입문) 교재에 실릴 Booster Quiz입니다.

교육 앞 부분의 문제인만큼, 인덱스 구조만 이해하면 누구라도 풀수 있는 수준의 문제입니다.
교재에 직접 손으로 그려보면서, "아~ 인덱스가 이렇게 작동하는구나"를 느낄 수 있는 간단한 문제입니다.
("입문" 교육이라고 말씀을 드리긴 하지만, 교육 중반 정도 넘어가면 어려운 문제들이 나옵니다.)

교육은 언제나 진정성 있게 하자란 생각으로, 교재도 공을 들여 준비중입니다.

 

 

 

 


[StartUP Tuning]

  - SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 입문 교육
  - 2024년 5월 오프라인 교육 과정 모집중: https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

[StartUP SQL]

  - 데이터 분석가, 개발자, 기획자를 위한 SQL 입문 교육

  - 교육용 슬라이드 전체 무료 오픈: https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드 전체를 블로그에 무료 오픈했습니다. (총 409장 슬라이드, 이미지로 게시) 아래 목차를 차례대로 하나씩 따라해보시기 바랍니다. 본인의

sweetquant.tistory.com

 

 

 

 

오늘은 StartUP Tuning 강의 중 일부인 "언제까지 인덱스를 탈 것만 같아?" 부분을 소개해봅니다.

MySQL로 데이터를 조회할 때 언제까지 인덱스를 사용하는지, 언제나 인덱스가 좋은 것인지에 대한 내용입니다.


SQL의 성능을 위해서는 기본적으로 세 개의 요소가 필요합니다. StartUP Tuning에서는 아래와 같이 세 개의 요소를 정의합니다.

  • INDEX
  • 비효율 SQL 변경(제거)
  • 힌트 사용

이 외에도 SQL 성능을 위해 다양한 요소가 필요하겠지만 기본적으로 가장 신경써야 할 부분은 위의 세 가지입니다.

 

SQL 성능을 위해 인덱스를 잘 구성해야 합니다. 기본적인 인덱스 구성 없이 SQL 성능을 끌어 올리는 것은 불가능합니다.

그러나 인덱스가 잘 구성되어 있어도 SQL을 잘 작성하지 않는다면 아무 필요가 없습니다.

(StartUP Tuning 강의에서는 인덱스를 하루에 걸쳐 설명하지만, 항상 SQL의 중요성을 강조합니다.)

SQL이 실행되면 MySQL의 옵티마이져는 상황에 따라서 인덱스로 처리할지 테이블 FULL SCAN으로 처리할지 선택하게 됩니다. 이는 인덱스를 사용하는 것이 항상 성능에 유리하지는 않다는 뜻이기도 합니다.

 

아래와 같은 SQL의 조건을 변경해가면서 실행하면, 어느 지점부터 인덱스가 아닌 FULL SCAN을 선택하는지 간단히 살펴볼 수 있습니다. T_ORD_BIG에는 약 6백만건의 데이터가 존재하며 ORD_YMD 컬럼에 싱글 컬럼 인덱스가 존재합니다. SELECT 절에 일부러 인덱스에 없는 PAY_DT 컬럼을 사용해 인덱스를 사용한 후 테이블 접근이 발생하도록 유도했습니다. 

SELECT  MAX(T1.PAY_DT) MAX_PAY_DT, COUNT(*) CNT
FROM    T_ORD_BIG T1 
WHERE   T1.ORD_YMD >= '20170104'
AND     T1.ORD_YMD <  '20170110';

 

조회 조건을 변경해가면서 테스트를 해보면 아래와 같은 결과를 얻을 수 있습니다. 조회 건수가 450,000 건 정도가 되자 인덱스가 아닌 Table Scan(TABLE FULL SCAN)을 선택했습니다. (이는 인덱스로 데이터를 탐색 후 테이블 접근이 발생하는 것이 전제된 경우입니다. 만약에 테이블 접근 없이 인덱스만 사용한다면 다른 결과가 나올 것입니다.) 실행시간 역시 342,000건 까지는 1.75초 정도였으나 450,000건인 Table Scan부터는 7.05 초로 매우 느려진 것을 알 수 있습니다.

 

MySQL의 옵티마이져는 통계를 참고해 450,000건 정도부터는 인덱스보다는 Table Scan이 더 빠르다 판단한 것입니다. 

항상 옵티마이져가 최선의 선택을 하는 것은 아닙니다. 최선의 선택을 위해 주어진 환경에서 최대한 노력하지만, 최선의 선택이 아닐 수도 있습니다. 실제로 현재 환경에서 450,000건 정도는 Table Scan보다 인덱스를 활용한 처리가 더 빠릅니다. 위 결과를 시각화 해보면 다음과 같습니다. Table Scan(FULL SCAN)에서 Buffers(IO) 수치는 꺽이지만 실행 시간은 오히려 7초대까지 올라간 것을 알 수 있습니다.

 

여기서 주의할 점이 있습니다. 450,000이 Table Scan을 선택하는 일반화된 숫자가 절대 아니라는 점입니다. 이러한 숫자는 서버와 디스크 성능, 서버 설정, 테이블의 크기(로우x컬럼), 인덱스 구성, 통계, SQL문 등에 의해 다른 결과가 나올 수 있습니다. 제 개인 PC에 설치된 MySQL에서 이와 같은 수치가 나온 것이므로 각자 환경에서 큰 테이블을 기준으로 테스트 해보시기 바랍니다.

 

추가로 하나의 테스트를 더 해 봅니다. 조회 건수를 변경해가면서 INDEX 또는 NO_INDEX 힌트를 적용해 성능 비교를 하는 것입니다. 아래와 같은 결과를 얻을 수 있습니다.

 

450,000건을 처리할 때 인덱스를 사용한 경우에는 3.28초 정도의 시간이 걸린 것을 알 수 있습니다. 해당 건수의 FULL SCAN 시간은 6.64초 정도가 나왔습니다. (이전 테스트에서 7.05초 정도였습니다. 약간 시간이 줄어들었으나 크게 의미는 없습니다.)

위 내용을 시각화 해보면 다음과 같습니다.

 

Table Scan(FULL SCAN)은 몇 건의 데이터를 조회하든 거의 일정한 시간과 거의 일정한 IO를 유지합니다. 반면에 인덱스를 이용한 데이터 접근은 어느 순간(450,000 건을 넘어서는 순간)부터 IO와 실행시간이 급등하기 시작합니다.

이처럼 조회할 데이터가 많아질 수록 인덱스보다 Table Scan(FULL SCAN)이 SQL 성능을 위해 더 좋은 선택일 수 있습니다. (한번 더 강조하면, 이와 같은 수치는 테스트 환경에 따라 상이합니다.)

 

조회할 데이터가 많으면 Table Scan이 더 좋다! 그러나, SQL 튜닝에 많은 도움을 주시는 변동구 이사님께서 이런 말씀을 하셨습니다. "지금도 빠르고 앞으로도 빠를 것인가?"

현재 테스트한 T_ORD_BIG에는 6백만건 정도의 데이터가 있습니다.

데이터가 지금의 열 배가 된다면, 여전히 Table Scan(FULL SCAN)이 인덱스를 활용한 검색보다 빠를 수 있을지는 생각을 해볼 필요가 있습니다.

 

StartUP Tuning(MySQL을 활용한 SQL 튜닝 입문 교육)에서는 지금까지의 내용을 다음과 같은 슬라이드로 소개합니다.

 

 

 


오늘 준비한 내용은 여기까지입니다. 정리해보면 다음과 같습니다.

  • 옵티마이져는 데이터 처리량에 따라 인데스와 Table Scan 중에 선택을 한다.
  • 옵티마이져의 선택이 완벽하지 않을 수도 있다.
  • 실제로 처리할 건수가 많아질 수록 인덱스보다는 Table Scan이 더 효과적이다.
  • 그러나 "지금도 빠르고 앞으로도 빠를것인가?" 에 대해 고민해보자.

감사합니다.


[StartUP Tuning]

  - SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 입문 교육
  - 2024년 5월 오프라인 교육 과정을 모집중입니다.

  - https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

[StartUP SQL]

  - 데이터 분석가, 개발자, 기획자를 위한 SQL 입문 교육

  - 교육용 슬라이드 전체 무료 오픈: https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드 전체를 블로그에 무료 오픈했습니다. (총 409장 슬라이드, 이미지로 게시) 아래 목차를 차례대로 하나씩 따라해보시기 바랍니다. 본인의

sweetquant.tistory.com

 

 

분석대상을 로우별로 다르게 지정할 수 있는 윈도윙절입니다.

그리고 준비한 자료는 여기까지입니다. 수고하셨습니다.^^

 

 


이전 슬라이드: https://sweetquant.tistory.com/549

다음 슬라이드: 마지막입니다. 

StartUP SQL 교육 슬라이드 전체 목차로 이동

https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

데이터를 강력하게 다루는 SQL! SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드를 이미지로 블로그에 무료 오픈했습니다. (총 409장의 슬라이드입니다.) 아래 목차를 차례대로 하나씩 따

sweetquant.tistory.com

 

SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 교육 [StartUP Tuning] 오프라인 교육 과정을 모집중입니다.

https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

 

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

20-2. LAG와 LEAD  (0) 2024.04.11
20-1. PARTITION BY  (0) 2024.04.11
19-4. GROUP BY와 분석함수  (0) 2024.04.11
19-3. 순위 분석함수  (0) 2024.04.11
19-1~19-2. 분석함수 이해하기  (0) 2024.04.11
18. 날짜 테이블  (0) 2024.04.11
17. PIVOT  (0) 2024.04.11
16-3. ROLLUP  (0) 2024.04.11

다른 로우의 데이터를 현재 로우로 가져올 수 있는 LAG와 LEAD를 살펴보겠습니다.

 

 


이전 교육 슬라이드: https://sweetquant.tistory.com/548
다음 교육 슬라이드: https://sweetquant.tistory.com/550
StartUP SQL 교육 슬라이드 전체 목차: https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

데이터를 강력하게 다루는 SQL! SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드를 이미지로 블로그에 무료 오픈했습니다. (총 409장의 슬라이드입니다.) 아래 목차를 차례대로 하나씩 따

sweetquant.tistory.com

 

SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 교육 [StartUP Tuning]
2024년 5월 오프라인 교육 과정을 모집중입니다.
https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

20-3. WINDOWING  (0) 2024.04.11
20-1. PARTITION BY  (0) 2024.04.11
19-4. GROUP BY와 분석함수  (0) 2024.04.11
19-3. 순위 분석함수  (0) 2024.04.11
19-1~19-2. 분석함수 이해하기  (0) 2024.04.11
18. 날짜 테이블  (0) 2024.04.11
17. PIVOT  (0) 2024.04.11
16-3. ROLLUP  (0) 2024.04.11

분석함수에서 분석대상을 나눌 수 있는 PARTITION BY의 용법입니다.

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

20-3. WINDOWING  (0) 2024.04.11
20-2. LAG와 LEAD  (0) 2024.04.11
19-4. GROUP BY와 분석함수  (0) 2024.04.11
19-3. 순위 분석함수  (0) 2024.04.11
19-1~19-2. 분석함수 이해하기  (0) 2024.04.11
18. 날짜 테이블  (0) 2024.04.11
17. PIVOT  (0) 2024.04.11
16-3. ROLLUP  (0) 2024.04.11

GROUP BY와 분석함수를 혼합해서 사용하는 법을 살펴보도록 하겠습니다.

 

 


이전 교육 슬라이드: https://sweetquant.tistory.com/546
다음 교육 슬라이드: https://sweetquant.tistory.com/548

 


StartUP SQL 교육 슬라이드 전체 목차: https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

데이터를 강력하게 다루는 SQL! SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드를 이미지로 블로그에 무료 오픈했습니다. (총 409장의 슬라이드입니다.) 아래 목차를 차례대로 하나씩 따

sweetquant.tistory.com


SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 교육 [StartUP Tuning]
2024년 5월 오프라인 교육 과정을 모집중입니다.
https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

20-3. WINDOWING  (0) 2024.04.11
20-2. LAG와 LEAD  (0) 2024.04.11
20-1. PARTITION BY  (0) 2024.04.11
19-3. 순위 분석함수  (0) 2024.04.11
19-1~19-2. 분석함수 이해하기  (0) 2024.04.11
18. 날짜 테이블  (0) 2024.04.11
17. PIVOT  (0) 2024.04.11
16-3. ROLLUP  (0) 2024.04.11

데이터의 순위를 구하는 분석함수입니다.

 

 

 


이전 교육 슬라이드: https://sweetquant.tistory.com/545
다음 교육 슬라이드: https://sweetquant.tistory.com/547

StartUP SQL 교육 슬라이드 전체 목차: https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

데이터를 강력하게 다루는 SQL! SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드를 이미지로 블로그에 무료 오픈했습니다. (총 409장의 슬라이드입니다.) 아래 목차를 차례대로 하나씩 따

sweetquant.tistory.com

 


SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 교육 [StartUP Tuning]
2024년 5월 오프라인 교육 과정을 모집중입니다.
https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

20-3. WINDOWING  (0) 2024.04.11
20-2. LAG와 LEAD  (0) 2024.04.11
20-1. PARTITION BY  (0) 2024.04.11
19-4. GROUP BY와 분석함수  (0) 2024.04.11
19-1~19-2. 분석함수 이해하기  (0) 2024.04.11
18. 날짜 테이블  (0) 2024.04.11
17. PIVOT  (0) 2024.04.11
16-3. ROLLUP  (0) 2024.04.11

데이터 분석을 위해 반드시 정복해야 할 분석함수에 대해 이해해보도록 하겠습니다.

 

 

 


이전 교육 슬라이드: https://sweetquant.tistory.com/544
다음 교육 슬라이드: https://sweetquant.tistory.com/546

StartUP SQL 교육 슬라이드 전체 목차: https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

데이터를 강력하게 다루는 SQL! SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드를 이미지로 블로그에 무료 오픈했습니다. (총 409장의 슬라이드입니다.) 아래 목차를 차례대로 하나씩 따

sweetquant.tistory.com


SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 교육 [StartUP Tuning]
2024년 5월 오프라인 교육 과정을 모집중입니다.
https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

20-2. LAG와 LEAD  (0) 2024.04.11
20-1. PARTITION BY  (0) 2024.04.11
19-4. GROUP BY와 분석함수  (0) 2024.04.11
19-3. 순위 분석함수  (0) 2024.04.11
18. 날짜 테이블  (0) 2024.04.11
17. PIVOT  (0) 2024.04.11
16-3. ROLLUP  (0) 2024.04.11
16-1~16.2. UNION ALL  (0) 2024.04.11

데이터 분석에 유용한 날짜 테이블과 날짜 테이블을 활용법을 살펴보겠습니다.

 

 

 


이전 교육 슬라이드: https://sweetquant.tistory.com/543
다음 교육 슬라이드: https://sweetquant.tistory.com/545

StartUP SQL 교육 슬라이드 전체 목차: https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

데이터를 강력하게 다루는 SQL! SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드를 이미지로 블로그에 무료 오픈했습니다. (총 409장의 슬라이드입니다.) 아래 목차를 차례대로 하나씩 따

sweetquant.tistory.com

 


SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 교육 [StartUP Tuning]
2024년 5월 오프라인 교육 과정을 모집중입니다.
https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

20-1. PARTITION BY  (0) 2024.04.11
19-4. GROUP BY와 분석함수  (0) 2024.04.11
19-3. 순위 분석함수  (0) 2024.04.11
19-1~19-2. 분석함수 이해하기  (0) 2024.04.11
17. PIVOT  (0) 2024.04.11
16-3. ROLLUP  (0) 2024.04.11
16-1~16.2. UNION ALL  (0) 2024.04.11
15-4. WITH  (0) 2024.04.04

데이터를 PIVOT 처리하는 SQL 패턴을 살펴보겠습니다.

 

 

 


이전 교육 슬라이드: https://sweetquant.tistory.com/542
다음 교육 슬라이드: https://sweetquant.tistory.com/544

StartUP SQL 교육 슬라이드 전체 목차: https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

데이터를 강력하게 다루는 SQL! SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드를 이미지로 블로그에 무료 오픈했습니다. (총 409장의 슬라이드입니다.) 아래 목차를 차례대로 하나씩 따

sweetquant.tistory.com

 


SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 교육 [StartUP Tuning]
2024년 5월 오프라인 교육 과정을 모집중입니다.
https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

19-4. GROUP BY와 분석함수  (0) 2024.04.11
19-3. 순위 분석함수  (0) 2024.04.11
19-1~19-2. 분석함수 이해하기  (0) 2024.04.11
18. 날짜 테이블  (0) 2024.04.11
16-3. ROLLUP  (0) 2024.04.11
16-1~16.2. UNION ALL  (0) 2024.04.11
15-4. WITH  (0) 2024.04.04
15-2~15-3. INLINE VIEW  (0) 2024.04.04

중간합계와 전체합계를 손쉽게 로우로 추가할 수 있는 ROLLUP에 대해 알아보도록 하겠습니다.

 

 


이전 교육 슬라이드: https://sweetquant.tistory.com/541
다음 교육 슬라이드: https://sweetquant.tistory.com/543

StartUP SQL 교육 슬라이드 전체 목차: https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

데이터를 강력하게 다루는 SQL! SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드를 이미지로 블로그에 무료 오픈했습니다. (총 409장의 슬라이드입니다.) 아래 목차를 차례대로 하나씩 따

sweetquant.tistory.com

 


SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 교육 [StartUP Tuning]
2024년 5월 오프라인 교육 과정을 모집중입니다.
https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

19-3. 순위 분석함수  (0) 2024.04.11
19-1~19-2. 분석함수 이해하기  (0) 2024.04.11
18. 날짜 테이블  (0) 2024.04.11
17. PIVOT  (0) 2024.04.11
16-1~16.2. UNION ALL  (0) 2024.04.11
15-4. WITH  (0) 2024.04.04
15-2~15-3. INLINE VIEW  (0) 2024.04.04
15-1. TOP-N  (0) 2024.04.04

데이터를 상하로 결합하는 UNION ALL에 대해 알아봅시다.

 

 

 


이전 교육 슬라이드: https://sweetquant.tistory.com/536
다음 교육 슬라이드: https://sweetquant.tistory.com/542

StartUP SQL 교육 슬라이드 전체 목차: https://sweetquant.tistory.com/497

SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 교육 [StartUP Tuning]
2024년 5월 오프라인 교육 과정을 모집중입니다.
https://cafe.naver.com/dbian/7717

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

19-1~19-2. 분석함수 이해하기  (0) 2024.04.11
18. 날짜 테이블  (0) 2024.04.11
17. PIVOT  (0) 2024.04.11
16-3. ROLLUP  (0) 2024.04.11
15-4. WITH  (0) 2024.04.04
15-2~15-3. INLINE VIEW  (0) 2024.04.04
15-1. TOP-N  (0) 2024.04.04
14-2. WHERE 절 서브쿼리  (0) 2024.04.04

WITH 절 사용법입니다.

 

 


이전 교육 슬라이드: https://sweetquant.tistory.com/535
다음 교육 슬라이드: https://sweetquant.tistory.com/541

StartUP SQL 교육 슬라이드 전체 목차: https://sweetquant.tistory.com/497\

 

StartUP SQL 소개 및 목차

데이터를 강력하게 다루는 SQL! SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드를 이미지로 블로그에 무료 오픈했습니다. (총 409장의 슬라이드입니다.) 아래 목차를 차례대로 하나씩 따

sweetquant.tistory.com

 


SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 교육 [StartUP Tuning]
2024년 5월 오프라인 교육 과정을 모집중입니다.
https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

18. 날짜 테이블  (0) 2024.04.11
17. PIVOT  (0) 2024.04.11
16-3. ROLLUP  (0) 2024.04.11
16-1~16.2. UNION ALL  (0) 2024.04.11
15-2~15-3. INLINE VIEW  (0) 2024.04.04
15-1. TOP-N  (0) 2024.04.04
14-2. WHERE 절 서브쿼리  (0) 2024.04.04
14-1. 스칼라 서브쿼리  (0) 2024.04.04

FROM 절에 사용하는 서브쿼리인 인라인 뷰에 대해 알아보시죠.

 

 


이전 교육 슬라이드: https://sweetquant.tistory.com/534
다음 교육 슬라이드: https://sweetquant.tistory.com/536

StartUP SQL 교육 슬라이드 전체 목차: https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

데이터를 강력하게 다루는 SQL! SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드를 이미지로 블로그에 무료 오픈했습니다. (총 409장의 슬라이드입니다.) 아래 목차를 차례대로 하나씩 따

sweetquant.tistory.com


SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 교육 [StartUP Tuning]
2024년 5월 오프라인 교육 과정을 모집중입니다.
https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

17. PIVOT  (0) 2024.04.11
16-3. ROLLUP  (0) 2024.04.11
16-1~16.2. UNION ALL  (0) 2024.04.11
15-4. WITH  (0) 2024.04.04
15-1. TOP-N  (0) 2024.04.04
14-2. WHERE 절 서브쿼리  (0) 2024.04.04
14-1. 스칼라 서브쿼리  (0) 2024.04.04
13-5. OUTER JOIN과 집계함수  (0) 2024.04.04

기본적인 SQL 문법은 이제 모두 배웠습니다.

데이터를 분석할때 사용할법한 내용을 조금만 더 배워보시면 될거 같습니다.

오늘은 Top-N을 추출하는 LIMIT 사용법입니다.

 

 


이전 교육 슬라이드: https://sweetquant.tistory.com/533
다음 교육 슬라이드: https://sweetquant.tistory.com/535

StartUP SQL 교육 슬라이드 전체 목차: https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

데이터를 강력하게 다루는 SQL! SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드를 이미지로 블로그에 무료 오픈했습니다. (총 409장의 슬라이드입니다.) 아래 목차를 차례대로 하나씩 따

sweetquant.tistory.com


SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 교육 [StartUP Tuning]
2024년 5월 오프라인 교육 과정을 모집중입니다.
https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

16-3. ROLLUP  (0) 2024.04.11
16-1~16.2. UNION ALL  (0) 2024.04.11
15-4. WITH  (0) 2024.04.04
15-2~15-3. INLINE VIEW  (0) 2024.04.04
14-2. WHERE 절 서브쿼리  (0) 2024.04.04
14-1. 스칼라 서브쿼리  (0) 2024.04.04
13-5. OUTER JOIN과 집계함수  (0) 2024.04.04
13-1~13-4. OUTER JOIN  (0) 2024.04.04

WHERE 절에도 서브쿼리를 사용할 수 있습니다.

보통은 EXISTS와 짝을 이루어 많이 사용됩니다.

우리가 WHERE 절 서브쿼리를 사용할 때 가장 주의해야 할 것은

메인 FROM 절과 서브쿼리 간에 값을 주거니 받거니 하는 순환 패턴입니다.

 

 

 

 

 

 


이전 교육 슬라이드: https://sweetquant.tistory.com/532
다음 교육 슬라이드: https://sweetquant.tistory.com/534

StartUP SQL 교육 슬라이드 전체 목차: https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

데이터를 강력하게 다루는 SQL! SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드를 이미지로 블로그에 무료 오픈했습니다. (총 409장의 슬라이드입니다.) 아래 목차를 차례대로 하나씩 따

sweetquant.tistory.com


SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 교육 [StartUP Tuning]
2024년 5월 오프라인 교육 과정을 모집중입니다.
https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

16-1~16.2. UNION ALL  (0) 2024.04.11
15-4. WITH  (0) 2024.04.04
15-2~15-3. INLINE VIEW  (0) 2024.04.04
15-1. TOP-N  (0) 2024.04.04
14-1. 스칼라 서브쿼리  (0) 2024.04.04
13-5. OUTER JOIN과 집계함수  (0) 2024.04.04
13-1~13-4. OUTER JOIN  (0) 2024.04.04
12-5. CROSS JOIN  (0) 2024.04.03

단일 값을 반환하는 SELECT 절의 서브쿼리(스칼라 서브쿼리)에 대해 알아보도록 하겠습니다.

 

 

 


이전 교육 슬라이드: https://sweetquant.tistory.com/531
다음 교육 슬라이드: https://sweetquant.tistory.com/533

StartUP SQL 교육 슬라이드 전체 목차: https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

데이터를 강력하게 다루는 SQL! SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드를 이미지로 블로그에 무료 오픈했습니다. (총 409장의 슬라이드입니다.) 아래 목차를 차례대로 하나씩 따

sweetquant.tistory.com


SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 교육 [StartUP Tuning]
2024년 5월 오프라인 교육 과정을 모집중입니다.
https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

15-4. WITH  (0) 2024.04.04
15-2~15-3. INLINE VIEW  (0) 2024.04.04
15-1. TOP-N  (0) 2024.04.04
14-2. WHERE 절 서브쿼리  (0) 2024.04.04
13-5. OUTER JOIN과 집계함수  (0) 2024.04.04
13-1~13-4. OUTER JOIN  (0) 2024.04.04
12-5. CROSS JOIN  (0) 2024.04.03
12-3~12-4. 여러 테이블의 JOIN  (0) 2024.04.03

기준집합 컬럼에 COUNT를 써야 하느냐, 참조집합 컬럼에 COUNT를 써야 하나. 그것이 문제로다.

 

 

 

 

 

 

 


이전 교육 슬라이드: https://sweetquant.tistory.com/530
다음 교육 슬라이드: https://sweetquant.tistory.com/532

StartUP SQL 교육 슬라이드 전체 목차: https://sweetquant.tistory.com/497

 

StartUP SQL 소개 및 목차

데이터를 강력하게 다루는 SQL! SQL을 배우기 위한 최적의 시작점 StartUP SQL! 교육 슬라이드를 이미지로 블로그에 무료 오픈했습니다. (총 409장의 슬라이드입니다.) 아래 목차를 차례대로 하나씩 따

sweetquant.tistory.com

 


SQL 입문을 넘어선 MySQL을 활용한 SQL 튜닝 교육 [StartUP Tuning]
2024년 5월 오프라인 교육 과정을 모집중입니다.
https://cafe.naver.com/dbian/7717

 

StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문

「StartUP Tuning - MySQL/MariaDB를 활용한 SQL 튜닝 입문」 < 일정 > 5/12(일), 5/19(일), 5/26(일) 오전 9시 ~ 오후 5시 (...

cafe.naver.com

 

'SQL > StartUP SQL(교육슬라이드)' 카테고리의 다른 글

15-2~15-3. INLINE VIEW  (0) 2024.04.04
15-1. TOP-N  (0) 2024.04.04
14-2. WHERE 절 서브쿼리  (0) 2024.04.04
14-1. 스칼라 서브쿼리  (0) 2024.04.04
13-1~13-4. OUTER JOIN  (0) 2024.04.04
12-5. CROSS JOIN  (0) 2024.04.03
12-3~12-4. 여러 테이블의 JOIN  (0) 2024.04.03
12-2. JOIN과 데이터 집합  (0) 2024.04.03

+ Recent posts