From ad15047bf3e6394011be8a6cf160fdfc0caf8488 Mon Sep 17 00:00:00 2001
From: ehdwoKIM <kinbell19@gmail.com>
Date: Mon, 19 Aug 2024 19:36:24 +0900
Subject: [PATCH 1/3] =?UTF-8?q?3=EC=9E=A5=5FSQL=ED=8A=9C=EB=8B=9D?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .idea/workspace.xml                           |   3 +-
 ...54\236\245-SQL\355\212\234\353\213\235.md" | 154 ++++++++++++++++++
 2 files changed, 156 insertions(+), 1 deletion(-)
 create mode 100644 "\354\227\205\353\254\264\354\227\220 \353\260\224\353\241\234 \354\223\260\353\212\224 SQL \355\212\234\353\213\235/\353\217\231\354\236\254/3\354\236\245-SQL\355\212\234\353\213\235.md"

diff --git a/.idea/workspace.xml b/.idea/workspace.xml
index e3fbfd5..9f94c6f 100644
--- a/.idea/workspace.xml
+++ b/.idea/workspace.xml
@@ -60,7 +60,8 @@
       <option name="presentableId" value="Default" />
       <updated>1722256642551</updated>
       <workItem from="1722256644322" duration="2806000" />
-      <workItem from="1722847771511" duration="8057000" />
+      <workItem from="1722847771511" duration="9768000" />
+      <workItem from="1724058019512" duration="5647000" />
     </task>
     <servers />
   </component>
diff --git "a/\354\227\205\353\254\264\354\227\220 \353\260\224\353\241\234 \354\223\260\353\212\224 SQL \355\212\234\353\213\235/\353\217\231\354\236\254/3\354\236\245-SQL\355\212\234\353\213\235.md" "b/\354\227\205\353\254\264\354\227\220 \353\260\224\353\241\234 \354\223\260\353\212\224 SQL \355\212\234\353\213\235/\353\217\231\354\236\254/3\354\236\245-SQL\355\212\234\353\213\235.md"
new file mode 100644
index 0000000..43ea398
--- /dev/null
+++ "b/\354\227\205\353\254\264\354\227\220 \353\260\224\353\241\234 \354\223\260\353\212\224 SQL \355\212\234\353\213\235/\353\217\231\354\236\254/3\354\236\245-SQL\355\212\234\353\213\235.md"	
@@ -0,0 +1,154 @@
+## 3장 - SQL 튜닝
+
+### 3.1 실습 환경 구성하기
+
+
+* 로컬 데이터베이스 목록 조회
+  <img width="475" alt="스크린샷 1" src="https://github.com/user-attachments/assets/ed41d578-5026-40e5-93bf-e6069144356c">
+
+
+* 데이터 존재 여부 확인
+  <img width="345" alt="스크린샷 2" src="https://github.com/user-attachments/assets/74b3f2a8-e1c8-46ce-bbbb-2a0756f14def">
+
+
+### 3.2 실행 계획 수행
+
+
+* MySQL 실행 계획 수행
+  <img width="926" alt="스크린샷 3" src="https://github.com/user-attachments/assets/2b3aab6f-ab78-45cb-815a-ad4d92d970d2">
+
+
+* 기본 실행 계획 항목 분석 - id
+  <img width="1119" alt="스크린샷 4" src="https://github.com/user-attachments/assets/ddc658ef-d017-43be-a3fe-d45f86073bf5">
+
+
+* 기본 실행 계획 항목 분석 - select_type (simple)
+  <img width="908" alt="스크린샷 5" src="https://github.com/user-attachments/assets/83543891-d662-4ed9-a875-accd0ea97650">
+  <img width="1090" alt="스크린샷 6" src="https://github.com/user-attachments/assets/9a5f9b3e-4e4d-4d0d-b3af-1fccef8acc04">
+
+
+* 기본 실행 계획 항목 분석 - select_type (primary)
+  <img width="1115" alt="스크린샷 7" src="https://github.com/user-attachments/assets/e2421448-6eea-4530-a6cd-4a4aa1a71648">
+  <img width="1415" alt="스크린샷 8" src="https://github.com/user-attachments/assets/c02b0d96-4c7b-4ba1-9618-c5c4bdd7c8bb">
+
+
+* 기본 실행 계획 항목 분석 - select_type (subquery)
+  <img width="1041" alt="스크린샷 9" src="https://github.com/user-attachments/assets/2f9d7287-26c7-43e1-8efe-f1514fafe6e1">
+
+
+* 기본 실행 계획 항목 분석 - select_type (derived)
+  <img width="1025" alt="스크린샷 10" src="https://github.com/user-attachments/assets/9ee7ba23-46c5-4fa5-a8ec-bc37af2d5641">
+
+
+* 기본 실행 계획 항목 분석 - select_type (union)
+  <img width="730" alt="스크린샷 11" src="https://github.com/user-attachments/assets/a5188c23-d813-42eb-8da7-b94fa4c45ee0">
+
+
+* 기본 실행 계획 항목 분석 - select_type (union result)
+  <img width="724" alt="스크린샷 12" src="https://github.com/user-attachments/assets/8f0b2af9-7e3b-41be-ad5b-fc47c0e87cee">
+
+
+* 기본 실행 계획 항목 분석 - select_type (dependent subquery)
+  <img width="744" alt="스크린샷 13" src="https://github.com/user-attachments/assets/41d281c5-6655-4d76-b815-fc156a601cee">
+
+
+* 기본 실행 계획 항목 분석 - select_type (dependent union)
+  <img width="744" alt="스크린샷 13" src="https://github.com/user-attachments/assets/41d281c5-6655-4d76-b815-fc156a601cee">
+
+
+* 기본 실행 계획 항목 분석 - select_type (uncacheable subquery)
+  <img width="739" alt="스크린샷" src="https://github.com/user-attachments/assets/da3849e3-b615-47e1-9af4-e2dc29e3fb2c">
+
+
+* 기본 실행 계획 항목 분석 - select_type (materialized)
+  <img width="734" alt="스크린샷" src="https://github.com/user-attachments/assets/26554847-b844-4dcf-82e8-cb70385309e6">
+
+
+* 기본 실행 계획 항목 분석 - table
+  <img width="737" alt="스크린샷 " src="https://github.com/user-attachments/assets/029a8cf2-b6d8-41c6-a5d0-951ab402b76a">
+
+
+* 기본 실행 계획 항목 분석 - type (system)
+  <img width="742" alt="스크린샷 " src="https://github.com/user-attachments/assets/a583287e-e033-4b77-8113-0e28703294eb">
+
+
+* 기본 실행 계획 항목 분석 - type (const)
+  <img width="734" alt="스크린샷" src="https://github.com/user-attachments/assets/3f6285e1-9ff9-4d49-aa9d-7fe192560b1e">
+
+
+* 기본 실행 계획 항목 분석 - type (eq_ref)
+  <img width="733" alt="스크린샷" src="https://github.com/user-attachments/assets/13106e25-14cc-4a5d-988c-a956959a2a5a">
+
+
+* 기본 실행 계획 항목 분석 - type (ref)
+  <img width="766" alt="스크린샷 " src="https://github.com/user-attachments/assets/61906d30-9b83-44a9-98aa-1beac9be6e8f">
+  <img width="771" alt="스크린샷" src="https://github.com/user-attachments/assets/2b1da9cd-007d-44cd-9570-67c51d749502">
+
+
+* 기본 실행 계획 항목 분석 - type (ref_or_null)
+  <img width="772" alt="스크린샷" src="https://github.com/user-attachments/assets/60e9edff-4cd5-4fcb-aa76-7a53623b1fe5">
+
+
+* 기본 실행 계획 항목 분석 - type (range)
+  <img width="770" alt="스크린샷" src="https://github.com/user-attachments/assets/709dba06-47e4-45c2-8ff0-a8bb05524848">
+
+
+* 기본 실행 계획 항목 분석 - type (index_merge)
+  <img width="768" alt="스크린샷 " src="https://github.com/user-attachments/assets/4ef4afca-cfdb-4bb6-96c1-1c0cb2422909">
+
+
+* 기본 실행 계획 항목 분석 - type (index)
+  <img width="743" alt="스크린샷 " src="https://github.com/user-attachments/assets/83dc3ba5-6e2d-4df4-a8f9-ef4dcd0c186f">
+
+
+* 기본 실행 계획 항목 분석 - type (all)
+  <img width="771" alt="스크린샷 " src="https://github.com/user-attachments/assets/ca164fd9-3d01-491d-bb6b-1daad264082f">
+
+
+* 기본 실행 계획 항목 분석 - key
+  <img width="766" alt="스크린샷" src="https://github.com/user-attachments/assets/a4380706-4ecb-4cfd-8207-92419dee55b6">
+
+
+* 기본 실행 계획 항목 분석 - key_len
+  <img width="743" alt="스크린샷 " src="https://github.com/user-attachments/assets/83dc3ba5-6e2d-4df4-a8f9-ef4dcd0c186f">
+
+
+* 기본 실행 계획 항목 분석 - ref
+  <img width="768" alt="스크린샷" src="https://github.com/user-attachments/assets/41623ec7-8f25-43a0-82bd-8d1615034412">
+
+
+* 기본 실행 계획 항목 분석 - extra (using index)
+  <img width="745" alt="스크린샷" src="https://github.com/user-attachments/assets/1a357bcd-05d0-408e-be08-cbbf0fd16aad">
+
+
+* MySQL의 확장된 실행 계획 수행 (explain format = traditional)
+  <img width="766" alt="스크린샷" src="https://github.com/user-attachments/assets/4a19fa38-2f4c-405b-9307-6f3851c9d5ce">
+
+
+* MySQL의 확장된 실행 계획 수행 (explain format = tree)
+  <img width="768" alt="스크린샷" src="https://github.com/user-attachments/assets/4ece992f-f9f4-49b0-b387-23730d3a4527">
+
+
+* MySQL의 확장된 실행 계획 수행 (explain format = json)
+  <img width="1200" alt="스크린샷" src="https://github.com/user-attachments/assets/f3e299ae-8827-48dc-a023-2ab8c0e485a7">
+
+
+* MySQL의 확장된 실행 계획 수행 (explain analyze)
+  <img width="741" alt="스크린샷" src="https://github.com/user-attachments/assets/3bd1ec5a-bac9-4f50-b629-77be5b825e6d">
+
+
+
+
+### 3.3 프로파일링
+
+
+* SQL 프로파일링 실행
+  <img width="555" alt="스크린샷" src="https://github.com/user-attachments/assets/ad274f0b-f918-4135-8a91-b0ba2cac62ea">
+  <img width="706" alt="스크린샷" src="https://github.com/user-attachments/assets/67187403-12e7-41de-b39a-36cc8b5b6ca2">
+  <img width="740" alt="스크린샷" src="https://github.com/user-attachments/assets/3d0a6010-50e2-4a9d-8d08-fecb4a43776e">
+
+
+* 프로파일링 결과 해석하기
+  <img width="745" alt="스크린샷" src="https://github.com/user-attachments/assets/2d0a0c23-831a-44ad-bca7-295a415ca827">
+  <img width="623" alt="스크린샷" src="https://github.com/user-attachments/assets/46ca0956-7d8f-4692-ba79-11fca2219a09">
+  <img width="621" alt="스크린샷 " src="https://github.com/user-attachments/assets/43605357-5e38-4cc0-bf8e-7c7133956445">

From f061c4f9bc2138e7e5119b158d2f48dfe092684d Mon Sep 17 00:00:00 2001
From: ehdwoKIM <kinbell19@gmail.com>
Date: Mon, 26 Aug 2024 13:47:30 +0900
Subject: [PATCH 2/3] =?UTF-8?q?4=EC=9E=A5=5F~194p?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .idea/workspace.xml                           |   3 +-
 .../4\354\236\245_~194p.md"                   | 237 ++++++++++++++++++
 2 files changed, 239 insertions(+), 1 deletion(-)
 create mode 100644 "\354\227\205\353\254\264\354\227\220 \353\260\224\353\241\234 \354\223\260\353\212\224 SQL \355\212\234\353\213\235/\353\217\231\354\236\254/4\354\236\245_~194p.md"

diff --git a/.idea/workspace.xml b/.idea/workspace.xml
index 9f94c6f..571b573 100644
--- a/.idea/workspace.xml
+++ b/.idea/workspace.xml
@@ -61,7 +61,8 @@
       <updated>1722256642551</updated>
       <workItem from="1722256644322" duration="2806000" />
       <workItem from="1722847771511" duration="9768000" />
-      <workItem from="1724058019512" duration="5647000" />
+      <workItem from="1724058019512" duration="13178000" />
+      <workItem from="1724645423484" duration="1663000" />
     </task>
     <servers />
   </component>
diff --git "a/\354\227\205\353\254\264\354\227\220 \353\260\224\353\241\234 \354\223\260\353\212\224 SQL \355\212\234\353\213\235/\353\217\231\354\236\254/4\354\236\245_~194p.md" "b/\354\227\205\353\254\264\354\227\220 \353\260\224\353\241\234 \354\223\260\353\212\224 SQL \355\212\234\353\213\235/\353\217\231\354\236\254/4\354\236\245_~194p.md"
new file mode 100644
index 0000000..35261a5
--- /dev/null
+++ "b/\354\227\205\353\254\264\354\227\220 \353\260\224\353\241\234 \354\223\260\353\212\224 SQL \355\212\234\353\213\235/\353\217\231\354\236\254/4\354\236\245_~194p.md"	
@@ -0,0 +1,237 @@
+## 4장 - 악성 SQL 튜닝으로 초보자 탈출하기
+
+
+### 4.1.1 테이블 데이터 및 인덱스 상태 점검
+
+* 테이블 데이터 건수 확인
+
+```sql
+SELECT COUNT(1)
+FROM 테이블명;
+```
+```
+COUNT(1)
+---------
+50000
+```
+
+* 테이블 인덱스 확인
+
+```sql
+SHOW INDEX FROM 테이블명;
+```
+```
+Table      Non_unique  Key_name    Seq_in_index  Column_name
+---------- ----------- ----------- ------------- ------------
+테이블명    0           PRIMARY     1             id
+테이블명    1           idx_name    1             name
+```
+
+
+### 4.1.2 SQL 튜닝 방향 설정
+
+* SQL 튜닝을 효과적으로 수행하기 위한 절차 :
+
+
+  SQL 실행 결과 및 상태 파악 -> SQL 쿼리 구성 요소 점검 -> 튜닝 방향 판단 및 적용
+
+1. SQL 실행 결과 및 상태 파악
+
+   * 결과 및 소요 시간: 쿼리 실행 결과와 시간을 기록
+   * 조인/서브쿼리 구조: 쿼리의 조인 및 서브쿼리 구조를 분석
+   * 동등/범위 조건: WHERE 절에서 사용하는 조건들을 확인
+
+
+2. SQL 쿼리 구성 요소 점검
+
+* 가시적 구성 요소
+  * 테이블 데이터 건수: 테이블의 데이터 건수를 확인하여 성능에 영향을 줄 수 있는 요소를 분석한다.
+     * 실무 사례: 대량의 데이터를 처리하는 경우 파티셔닝을 적용하여 성능을 최적화
+     
+  * SELECT 절 컬럼 분석: 필요한 컬럼만 선택하여 네트워크 트래픽을 줄이고 성능을 향상시킨다.
+     * 실무 사례: 불필요한 컬럼을 제거함으로써 조회 성능이 개선
+     
+  * 조건절 컬럼 분석: WHERE 절에서 사용되는 조건절에 적절한 인덱스를 적용한다.
+    * 실무 사례: 인덱스를 추가하여 검색 성능을 크게 향상
+     
+  * GROUP, ORDER 컬럼 분석: 그룹핑 및 정렬 작업에 인덱스를 적용하여 성능을 개선한다.
+    * 실무 사례: GROUP BY 및 ORDER BY 절에 인덱스를 생성하여 처리 시간 감소
+
+* 비가시적 구성 요소
+  * 실행 계획 분석: 실행 계획을 통해 불필요한 테이블 스캔을 인덱스 스캔으로 전환 가능하다.
+    * 실무 사례: 실행 계획 분석을 통해 성능 저하 원인을 파악하고 최적화
+    
+  * 인덱스 상태 점검: 사용되지 않는 인덱스를 제거하고 필요한 인덱스를 추가하여 성능을 최적화한다.
+    * 실무 사례: 인덱스 현황을 점검하여 최적화 포인트를 탐색
+
+  * 데이터 변경 추이 분석: 데이터 삽입, 갱신, 삭제 빈도를 고려하여 적절한 인덱스 전략을 적용한다.
+    * 실무 사례: 빈번한 데이터 변경이 발생하는 테이블에 적절한 인덱스를 적용하여 성능 개선
+  
+  * 업무적 특징 고려: 특정 시간대에 집중된 조회 요청에 맞춰 캐싱 전략을 도입한다.
+    * 실무 사례: 성능이 중요한 시간대에 적절한 캐시를 사용하여 성능 최적화
+
+
+3. 튜닝 방향 판단 및 적용
+   
+
+### 4.2 SQL 단순 수정으로 성능 개선 사례
+   사용하지 않는 구문이나 불필요한 구문을 제거하여 SQL 튜닝을 수행한다.
+   
+#### 4.2.1 SUBSTRING 사용 시 인덱스 미사용
+
+* 사원 번호가 '1100'으로 시작하는 5자리 사원 번호를 가진 사원의 정보를 조회하는 쿼리
+
+```sql
+SELECT *
+FROM 사원
+WHERE 
+	SUBSTRING(사원번호, 1, 4) = 1100
+	AND
+	LENGTH(사원번호) = 5;
+```
+
+#### 1. SQL 실행 결과 및 상태 파악
+
+실행 결과:
+
+```sql
+SELECT * FROM 사원 WHERE SUBSTRING(사원번호,1,4) = 1100  AND LENGTH(사원번호) = 5;
+```
+
+실행 계획:
+
+```sql
+EXPLAIN SELECT * FROM 사원 WHERE SUBSTRING(사원번호,1,4) = 1100  AND LENGTH(사원번호) = 5;
+```
+Type이 ALL로 인덱스를 사용하지 않고 전체 테이블을 스캔한다.
+
+
+#### 2. SQL 쿼리 구성 요소 점검
+
+사원 테이블에 약 30만 건의 데이터가 존재하며, 
+인덱스는 사원번호에 설정되어 있다.
+그러나 SUBSTRING(), LENGTH() 함수 사용으로 인해 인덱스를 활용하지 못하고 있는 것을 확인할 수 있다.
+
+#### 3. 튜닝 방향 판단 및 개선 적용
+
+기본키 검색이 가능하도록 BETWEEN 구문을 사용하여 쿼리를 수정한다.
+
+* 튜닝 후 쿼리:
+
+```sql
+SELECT *
+FROM 사원
+WHERE 사원번호 BETWEEN 11000 AND 11009;
+```
+
+* 튜닝 후 실행 결과: 실행 시간이 0.00초로 개선.
+
+EXPLAIN 결과에서 type이 range로 변경되어 인덱스를 활용한 검색이 이루어짐을 확인할 수 있다.
+
+
+#### 4.2.2. IFNULL 사용 시 주의사항
+
+* 사원 테이블에서 성별 기준으로 사원 수를 출력하는 쿼리이다.
+
+```sql
+SELECT IFNULL(성별,'NO DATA') AS 성별, COUNT(1) 건수
+FROM 사원
+GROUP BY IFNULL(성별, 'NO DATA');
+```
+
+#### 1. SQL 실행 결과 및 상태 파악
+
+- 실행 계획:
+
+Using temporary가 표시되어 임시 테이블을 사용하고 있음. IFNULL 함수로 인해 임시 테이블 생성
+
+#### 2. SQL 쿼리 구성 요소 점검
+
+성별 컬럼은 NOT NULL 속성이 적용되어 있어 IFNULL 사용이 필요하지 않음.
+
+#### 3. 튜닝 방향 결정 및 개선 적용
+
+- 튜닝 후 쿼리:
+```sql
+SELECT 성별, COUNT(1) 건수
+FROM 사원
+GROUP BY 성별;
+```
+
+- 튜닝 후 실행 결과:
+실행 시간: 0.08초로 개선,
+임시 테이블을 사용하지 않음
+
+  
+#### 4.2.3. 형 변환 시 인덱스 미활용 문제
+
+급여 테이블에서 유효한 급여 정보를 조회하는 쿼리
+
+```sql
+SELECT COUNT(1)
+FROM 급여
+WHERE 사용여부 = 1;
+```
+
+#### 1. SQL 실행 결과 및 상태 파악
+
+- 실행 시간: 0.42초, 약 4만 건의 데이터 조회
+
+- 실행 계획: 인덱스 풀 스캔이 발생하며, 형 변환으로 인한 문제를 확인
+
+#### 2. SQL 쿼리 구성 요소 점검
+
+사용 여부 컬럼이 char(1) 타입이지만 쿼리에서 숫자로 비교하고 있어 형 변환이 발생.
+
+#### 3. 튜닝 방향 결정 및 개선 적용
+
+- 튜닝 후 쿼리:
+```sql
+SELECT COUNT(1)
+FROM 급여
+WHERE 사용여부 = '1';
+```
+- 튜닝 후 실행 결과:
+
+실행 시간: 0.02초로 개선.
+EXPLAIN 결과에서 type이 ref로 변경되어 인덱스를 활용함을 확인
+
+#### 4.2.4 열 결합 시 인덱스 미활용 문제
+
+사원 테이블에서 성별과 성을 결합하여 검색하는 쿼리.
+
+```sql
+SELECT *
+FROM 사원
+WHERE CONCAT(성별, ' ', 성) = 'M Radwan';
+```
+
+#### 1. SQL 실행 결과 및 상태 파악
+
+- 실행 시간: 0.13초, 102건 조회
+
+- 실행 계획:
+
+ALL 타입으로 전체 테이블을 스캔
+
+#### 2. SQL 쿼리 구성 요소 점검
+
+WHERE 절을 통해 인덱스 활용이 가능하지만, CONCAT 사용으로 인해 풀 스캔이 발생.
+
+#### 3. 튜닝 방향 결정 및 개선 적용
+
+- 튜닝 후 쿼리:
+
+```sql
+SELECT *
+FROM 사원
+WHERE 성별 = 'M'
+AND 성 = 'Radwan';
+```
+
+- 튜닝 후 실행 결과:
+
+실행 시간: 0.00초로 개선
+EXPLAIN 결과에서 type이 ref로 변경되어 인덱스를 활용함을 확인.
+이와 같은 튜닝을 통해 SQL 성능을 개선 가능함.
+

From 348bc70fe0953aaa6d3abfe1d1bea128294283cc Mon Sep 17 00:00:00 2001
From: ehdwoKIM <kinbell19@gmail.com>
Date: Mon, 26 Aug 2024 18:05:13 +0900
Subject: [PATCH 3/3] =?UTF-8?q?4=EC=9E=A5=5F~232p?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .idea/workspace.xml                           |   3 +-
 .../4\354\236\245_~194p.md"                   | 324 ++++++++++++++++++
 2 files changed, 326 insertions(+), 1 deletion(-)

diff --git a/.idea/workspace.xml b/.idea/workspace.xml
index 571b573..becb71e 100644
--- a/.idea/workspace.xml
+++ b/.idea/workspace.xml
@@ -6,6 +6,7 @@
   <component name="ChangeListManager">
     <list default="true" id="166f7895-e525-43e3-8bd4-b83a0fa5dfde" name="변경" comment="">
       <change beforePath="$PROJECT_DIR$/.idea/workspace.xml" beforeDir="false" afterPath="$PROJECT_DIR$/.idea/workspace.xml" afterDir="false" />
+      <change beforePath="$PROJECT_DIR$/업무에 바로 쓰는 SQL 튜닝/동재/4장_~194p.md" beforeDir="false" afterPath="$PROJECT_DIR$/업무에 바로 쓰는 SQL 튜닝/동재/4장_~194p.md" afterDir="false" />
     </list>
     <option name="SHOW_DIALOG" value="false" />
     <option name="HIGHLIGHT_CONFLICTS" value="true" />
@@ -62,7 +63,7 @@
       <workItem from="1722256644322" duration="2806000" />
       <workItem from="1722847771511" duration="9768000" />
       <workItem from="1724058019512" duration="13178000" />
-      <workItem from="1724645423484" duration="1663000" />
+      <workItem from="1724645423484" duration="11473000" />
     </task>
     <servers />
   </component>
diff --git "a/\354\227\205\353\254\264\354\227\220 \353\260\224\353\241\234 \354\223\260\353\212\224 SQL \355\212\234\353\213\235/\353\217\231\354\236\254/4\354\236\245_~194p.md" "b/\354\227\205\353\254\264\354\227\220 \353\260\224\353\241\234 \354\223\260\353\212\224 SQL \355\212\234\353\213\235/\353\217\231\354\236\254/4\354\236\245_~194p.md"
index 35261a5..7607e67 100644
--- "a/\354\227\205\353\254\264\354\227\220 \353\260\224\353\241\234 \354\223\260\353\212\224 SQL \355\212\234\353\213\235/\353\217\231\354\236\254/4\354\236\245_~194p.md"	
+++ "b/\354\227\205\353\254\264\354\227\220 \353\260\224\353\241\234 \354\223\260\353\212\224 SQL \355\212\234\353\213\235/\353\217\231\354\236\254/4\354\236\245_~194p.md"	
@@ -235,3 +235,327 @@ AND 성 = 'Radwan';
 EXPLAIN 결과에서 type이 ref로 변경되어 인덱스를 활용함을 확인.
 이와 같은 튜닝을 통해 SQL 성능을 개선 가능함.
 
+
+#### 4.2.5 습관적으로 중복 제거하는 나쁜 SQL문
+
+부서 관리자의 사원번호와 이름, 성, 부서번호 데이터를 중복 제거 후 조회하는 쿼리
+
+```sql
+SELECT DISTINCT 사원.사원번호, 사원.이름, 사원.성, 부서관리자.부서번호
+FROM 사원
+JOIN 부서관리자
+ON (사원.사원번호 = 부서관리자.사원번호)
+```
+
+#### 1. SQL 실행 결과 및 상태 파악
+
+- 실행 시간 : 0.00초, 24건 조회
+- 실행 계획 : 부서관리자 테이블 (드라이빙 테이블), 사원 테이블(드리븐 테이블) 의 id값이 동일하므로 서로 조인한다
+
+#### 2. SQL 쿼리 구성 요소 점검
+
+type 항목이 index이므로 인덱스 풀 스캔 발생.
+DISTINCT 수행을 위해 별도 테이블 확보
+
+#### 3. 튜닝 방향 결정 및 개선 적용
+
+- 튜닝 후 쿼리 :
+```sql
+SELECT 사원.사원번호, 이름, 성, 부서번호
+FROM 사원
+JOIN 부서관리자
+ON (사원.사원번호 = 부서관리자.사원번호)
+```
+- 튜닝 후 실행 결과 :
+수행 결과 데이터 처리량이 적어 소요 시간 변화는 크게 없고,
+이후 실행 계획의 튜닝 결과로 확인.
+```sql
+EXPLAIN
+SELECT 사원.사원번호, 이름, 성, 부서번호
+FROM 사원
+JOIN 부서관리자
+ON (사원.사원번호 = 부서관리자.사원번호)
+```
+- 튜닝 후 실행 계획 :
+SQL 문에서 DISTINCT 키워드를 제거 후 튜닝하여 정렬과 중복 제거 수행이 필요하지 않다.
+
+
+#### 4.2.6 다수 쿼리를 UNION 연산자로만 합치는 나쁜 SQL문
+
+성이 Baba이며 성별이 M인 사원 데이터 조회 & 성이 Baba이며 성별이 F인 데이터를 조회
+```sql
+SELECT 'M' AS 성별, 사원번호
+FROM 사원
+WHERE 성별 = 'M'
+AND 성 = 'Baba'
+
+UNION 
+
+SELECT 'F', 사원번호
+FROM 사원
+WHERE 성별 = 'F'
+AND 성 = 'Baba'
+```
+
+#### 1. SQL 실행 결과 및 상태 파악
+- 실행 시간 : 0.01초, 226건 조회
+- 실행 계획 : 첫번째 select문은 I_성별_성_인덱 사용, 두번째 select문에서도 마찬가지로 사용.
+마지막 행에서는 두 행의 결과를 통합 후 중복 제거
+
+#### 2. SQL 쿼리 구성 요소 점검
+
+WHERE 절에 성별, 성 열이 동등 조건이기 때문에 인덱스 활용하여 빠르게 조회.
+UNION으로 SELECT문 두개가 통합될 때 중복 제거후 출력.
+
+#### 3. 튜닝 방향 결정 및 개선 적용
+
+- 튜닝 후 쿼리 : 
+```sql
+SELECT 'M' AS 성별, 사원번호
+FROM 사원
+WHERE 성별 = 'M'
+AND 성 = 'Baba'
+
+UNION ALL
+
+SELECT 'F', 사원번호
+FROM 사원
+WHERE 성별 = 'F'
+AND 성 = 'Baba'
+```
+- 튜닝 후 실행 결과 : 중복 제거 UNION 대신 결과값 합치는 UNION ALL.
+튜닝 전과 결과는 같고, 소요시간 기준이 아닌 이후 실행 계획으로 판단.
+
+- 튜닝 후 실행 계획 : UNION ALL로 불필요한 중복 제거 작업을 제외.
+
+
+#### 4.2.7 인덱스 고려 없이 열을 사용하는 나쁜 SQL문
+
+성과 성별 순서로 그루핑하여 데이터 개수를 조회하는 쿼리
+```sql
+SELECT 성, 성별, COUNT(1) as 카운트
+FROM 사원
+GROUP BY 성, 성별
+```
+
+#### 1. SQL 실행 결과 및 상태 파악
+
+- 실행 시간 : 0.32초, 3274건 조회
+- 실행 계획 : 임시 테이블 생성하여 성과 성별을 그루핑해 카운트 연산 수행
+
+#### 2. SQL 쿼리 구성 요소 점검
+
+성별 성 인덱스는 성별 열과 성 열 순으로 생성된 오브젝트.
+성별 기준 정렬 후에 성 열 기준으로 정렬되었기 떄문에, 인덱스 순서 활용
+
+#### 3. 튜닝 방향 결정 및 개선 적용
+
+- 튜닝 후 쿼리 :
+```sql
+SELECT 성, 성별, COUNT(1) as 카운트
+FROM 사원
+GROUP BY 성별, 성
+```
+- 튜닝 후 실행 결과 : 튜닝 후 0.04초로 소요시간 개선.
+
+
+#### 4.2.8 엉뚱한 인덱스를 사용하는 나쁜 SQL문
+
+사원 테이블에서 입사일자 값이 '1989'로 시작하여 사원번호가 100000를 초과하는 데이터 조회하는 쿼리
+```sql
+SELECT 사원번호
+FROM 사원
+WHERE 입사일자 LIKE '1989%'
+AND 사원번호 > 100000
+```
+
+#### 1. SQL 실행 결과 및 상태 파악
+
+- 실행 시간 : 0.13초, 20001건 조회
+- 실행 계획 : 사원 테이블의 기본 키로 범위 스캔. 사원번호로 데이터를 가져오고, 남은 필터 조건으로 filter
+
+#### 2. SQL 쿼리 구성요소 점검
+
+type 항목의 범위 스캔은 사원번호로 구성된 기본 키.
+스토리지 엔진에서 데이터 접근 시에 기본 키로 액세스하는 방법이 효율적인가?
+입사일자 열을 데이터 액세스 조건으로 활용.(USE INDEX 힌트 설정)
+
+#### 3. 튜닝 방향 결정 및 개선 적용
+
+- 튜닝 후 쿼리 :
+```sql
+SELECT 사원번호
+FROM 사원
+WHERE 입사일자 >= '1989-01-01' AND 입사일자 < '1990-01-01'
+  AND 사원번호 > 100000;
+```
+- 튜닝 후 실행 결과 : 소요시간이 0.02초로 감소.
+
+
+#### 4.2.9 동등 조건으로 인덱스를 사용하는 나쁜 SQL문
+
+B 출입문으로 출입한 이력이 있는 정보를 모두 조회하는 WHERE절 조건 쿼리.
+```sql
+SELECT *
+FROM 사원출입기록
+WHERE 출입문 = 'B'
+```
+
+#### 1. SQL 실행 결과 및 상태 파악
+
+- 실행 시간 : 3.7초, 30만 건 조회
+- 실행 계획 : 출입문 인덱스로 데이터 접근. 출입문 B를 상수화 조건으로 접근 범위를 축소.
+ref 항목이 const로 출력
+
+#### 2. SQL 쿼리 구성요소 점검
+
+I_출입문 인덱스로 인덱스 스캔. but, 인덱스 접근 뒤에 테이블에 랜덤 액세스하는 현재 방법이 효율적인가? (전체 데이터의 50% 조회인데?)
+
+#### 3. 튜닝 방향 결정 및 개선 적용
+
+- 튜닝 후 쿼리 :
+```sql
+SELECT *
+FROM 사원출입기록 IGNORE INDEX(I_출입문)
+WHERE 출입문 = 'B'
+```
+- 튜닝 후 실행 결과 : 소요 시간이 0.85초로 크게 감소.
+- 튜닝 후 실행 계획 : 사원출입기록 테이즐이 테이블 풀 스캔 방식 사용.
+-> 인덱스 사용하지 않고 where 조건절로 필요한 데이터만 추출. -> 랜덤 액세스 발생 X
+
+
+#### 4.2.10 범위 조건으로 인덱스를 사용하는 나쁜 SQL 문
+
+입사일자 기간 내 사원들의 이름, 성을 출력하는 쿼리
+```sql
+SELECT 이름, 성
+FROM 사원
+WHERE 입사일자 BETWEEN STR_TO_DATE('1994-01-01', '%Y-%m-%d') AND STR_TO_DATE('2000-12-31', '%Y-%m-%d')
+```
+
+#### 1. SQL 실행 결과 및 상태 파악
+
+- 실행 시간 : 1.21초, 48875건 조회
+- 실행 계획 : 사원 테이블에서 입사일자 인덱스로 범위 스캔.
+Using index condition의 입사일자 조건절로 인덱스 스캔 수행, Using MRR로 순차 스캔으로 처리됨
+
+#### 2. SQL 쿼리 구성요소 점검
+
+전체 데이터의 약 17%를 가져오는데 인덱스 사용이 효율적인지 테이블 바로 접근이 효율적인지?
+만약 매번 입사일자 열 기준으로 데이터 조회하는 경우가 잦다면, 테이블 풀 스캔 방식으로 고정하는 게 나음.
+
+#### 3. 튜닝 방향 결정 및 개선 적용
+
+- 튜닝 후 쿼리 :
+```sql
+SELECT 이름, 성
+FROM 사원
+WHERE YEAR(입사일자) BETWEEN '1994' AND '2000'
+```
+- 튜닝 후 실행 결과 : 소요 시간이 1.21초에서 0.2초로 감소함.
+- 튜닝 후 실행 계획 : 테이블 풀 스캔 방식으로 데이터에 접근. 인덱스 없이 접근하여 한번에 효율적으로 다수의 페이지에 접근 가능.
+
+
+### 4.3 테이블 조인 설정 변경으로 착한 쿼리 만들기
+
+조인 알고리즘은 대부분 중첩 루프 조인에 기반을 두므로 튜닝 분석 시 실행 게획을 잘 분석해 보자.
+
+#### 4.3.1 작은 테이블이 먼저 조인에 참여하는 나쁜 SQL 문
+
+부서사원_매핑 테이블과 부서 테이블 조인하여 부서 시작일자가 '2002-03-01' 이후인 사원 데이터 조회하는 쿼리
+```sql
+SELECT 매핑.사원번호, 부서.부서번호
+FROM 부서사원_매핑 매핑, 부서
+WHERE 매핑.부서번호 = 부서.부서번호
+AND 매핑.시작일자 >= '2002-03-01';
+```
+
+#### 1. SQL 실행 결과 및 상태 파악
+
+- 실행 시간 : 13.2초, 1341건 조회
+- 실행 계획 : 드라이빙 테이블인 부서 테이블과 드리븐 테이블인 부사사원_매핑 테이블이 중첩 루프 조인 수행.
+UI_부서명 인덱스를 활용하여 인덱스 풀 스캔.
+부서사원 매핑 테이블은 I_부서번호 인덱스로 인덱스 스캔.
+이때 드리븐 테이블에서 대량의 데이터에 랜덤 액세스하게 되면 비효율적임.
+
+#### 2. SQL 쿼리 구성요소 점검
+
+SQL문의 조건절로 추출한 부서사원_매핑 테이블의 건수는 전체 데이터 건수 대비 0.4%이다.
+따라서 상대적으로 규모가 큰 부서사원_매핑 테이블의 시작일자 조건절을 먼저 적용하게 되면 조인 시에 비교대상이 감소함.
+
+#### 3. 튜닝 방향 결정 및 개선 적용
+
+- 튜닝 후 쿼리 :
+```sql
+SELECT STRAIGHT_JOIN 매핑.사원번호, 부서.부서번호
+FROM 부서사원_매핑 매핑, 부서
+WHERE 매핑.부서번호 = 부서.부서번호
+AND 매핑.시작일자 >= '2002-03-01'
+```
+- 튜닝 후 실행 결과 : 소요시간이 0.17초로 크게 감소됨
+
+
+#### 4.3.2 메인 테이블에 계속 의존하는 나쁜 SQL문
+
+사원번호가 450000보다 크고 최대 연봉이 100000 보다 큰 데이터를 찾아 출력하는 쿼리
+```sql
+SELECT 사원.사원번호, 사원.이름, 사원.성
+FROM 사원
+WHERE 사원번호 > 450000
+AND (SELECT MAX(연봉) FROM 급여 WHERE 사원번호 = 사원.사원번호) > 100000
+```
+
+#### 1. SQL 실행 결과 및 상태 파악
+
+- 실행 시간 : 0.57초, 3155건 조회
+- 실행 계획 : 사원 테이블 기본키로 범위 스캔 후 급여 테이블에 접근
+
+#### 2. SQL 쿼리 구성요소 점검
+
+튜닝 대상 SQL문의 인덱스는 모두 기본키임.
+select_type의 DEPENDENT가 있으면 외부 테이블에서 조건절을 받고 처리되므로 튜닝 대상으로 고려.
+서브쿼리 -> 조인으로 변경?
+
+#### 3. 튜닝 방향 결정 및 개선 적용
+
+- 튜닝 후 쿼리 :
+```sql
+SELECT 사원.사원번호, 사원.이름, 사원.성
+FROM 사원, 급여
+WHERE 사원번호 > 450000
+AND 사원.사원번호 = 급여.사원번호
+GROUP BY 사원.사원번호
+HAVING MAX(급여.연봉) > 100000
+```
+- 튜닝 후 실행 결과 : 0.11초로 소요시간 감소.
+
+
+#### 4.3.3 불필요한 조인을 수행하는 나쁜 SQL문
+
+FROM절에서 사원 테이블과 사원출입기록 테이블로 작성한 인라인 뷰를 사원번호 열로 내부 조인하는 쿼리
+```sql
+SELECT COUNT(DISTINCT 사원.사원번호) as 데이터건수
+FROM 사원, (SELECT 사원번호 FROM 사원출입기록 기록 WHERE 출입문 ='A') 기록
+WHERE 사원.사원번호 = 기록.사원번호
+```
+
+#### 1. SQL 실행 결과 및 상태 파악
+
+- 실행 시간 : 22.5초, 1건 조회
+- 실행 계획 : 사원출입기록 테이블(드라이빙 테이블)은 I_출입문 인덱스로 A 출입문에 관한 기록의 사원번호 추출.
+사원 테이블(드리븐 테이블) 은 기본키로 조인 조건절인 사원번호 열로 데이터를 비교
+
+#### 2. SQL 쿼리 구성요소 점검
+
+FROM절의 인라인 뷰는 옵티마이저에 의해 뷰 병합으로 조인이 최적화됨.
+즉 SELECT 절의 최종결과는 사원 테이블의 사원번호에서 중복 제거한 건수.
+
+#### 3. 튜닝 방향 결정 및 개선 적용
+
+- 튜닝 후 쿼리 :
+```sql
+SELECT COUNT(1) as 데이터건수
+FROM 사원
+WHERE EXISTS(SELECT 1 FROM 사원출입기록 기록 WHERE 출입문 ='A' AND 기록.사원번호 = 사원.사원번호)
+```
+- 튜닝 후 실행 결과 : 15만 건의 데이터가 1행으로 출력. 소요 시간은 0.5초로 개선.
\ No newline at end of file