**기본**일반적인 쿼리 실행 순서1. 조인, WHERE2. GROUP BY3. DISTINCT4. HAVING 조건 적용5. ORDER BY6. LIMIT 특수한 경우 쿼리 실행 순서1. WHERE 적용2. ORDER BY3. 조인4. LIMIT(위의 두 실행 순서로 판단하겠습니다.) 조인에 대해 Store/User와 같이 복잡하지 않고, 하나의 레코드에 한명의 유저만 접근하는 도메인에는 굳이 쿼리 최적화/동시성 보장을 할 우선순위가 현저하게 낮은 부분은 제외하겠습니다.1. Feed 쿼리 최적화 public Long countAllByFiltering(boolean isAvailable, Category category, String keyword) { return jpaQueryF..
MySQL
1. NLJ(스트리밍/파이프라인 방식)=> 인덱스를 탈 수 있는 쿼리에서는 옵티마이저는 무조건 NLJ 방식을 사용한다.=> NLJ는 Nested Loop Join으로 그냥 루프를 돌려 조인을 수행한다고 보면 된다.1-1. NLJ는 비교적 중요하다 볼 수 있어, 별개의 글을 남긴다.https://icanchangeworld.tistory.com/168 우선, JOIN을 최적화하기 위해서는 NLJ에 대해 알아야 한다.=> Nested Left Join은 2개의 조인된 테이블이 있다고 가정했을 때,=> 인덱스로 조인 조건을 필터링(?)해 더 빠르게 찾도록 최" data-og-host="icanchangeworld.tistory.com" data-og-source-url="https://icanchangewor..
학습목표 : 실행 계획을 분석해보고 SQL 작성 방법 및 쿼리 최적화 방법을 익힌다. 1번쿼리SELECT s.emp_no, COUNT(DISTINCT e.first_name) AS cntFROM salaries s INNER JOIN employees e ON e.emp_no=s.emp_noWHERE s.emp_no IN (100001, 100002)GROUP BY s.emp_no HAVING AVG(s.salary) > 1000ORDER BY AVG(s.salary) LIMIT 10; ++ salaries의 PK는 emp_no이고, employees의 PK도 emp_no이다.=> 스트리밍 방식으로 처리한다.=> 그룹화를 평균 salary가 1000 초과인 것들만 한다.=> salary로 정렬한다.=> ..
group by -그룹으로 묶는 키워드 -select 시 집계 함수나, 어떠한 값들이 있는지 볼 수 있음 1. 인덱스를 사용하는 group by 스캔 -> group by는 기본적으로 집계함수, distinct 같은 역할을 수행할 수 있음 -> 집계함수는 모든 레코드를 읽어야 집계가 가능하기 때문에 기본적으로 풀 스캔임 -> 그러한 역할을 수행하는 group by 또한 풀 스캔을 수행해야함 -> 이때, 옵티마이저는 스캔을 최적화하고자 풀 스캔말고 다른 스캔들을 사용할 수 있음 ex)SELECT emp_no FROM salaries WHERE from_date='1985-03-01' GROUP BY emp_no 인덱스(emp_no, from_date) 1-1. 루스 스캔 -> 멀티 밸류 인덱스일때 2번째 ..
ORDER BY 1. 정렬을 수행하는 키워드2. 정렬 방법2-1. 인덱스를 이용한 정렬-> b+tree의 리프노드 페이지에 인덱스 값에 따라 이미 정렬되어 있음 -> 그냥 인덱스를 읽으면 됨2-2. 인덱스를 이용하지 않은 FileSort-> 매우 많은 양의 데이터를 정렬해야한다 가정 -> 데이터를 정렬하는 작업은 메모리 위에서 실행된다. -> 메모리에 그 많은 데이터를 한번에 가져올 수 없다. -> 소트 버퍼라는 정렬을 수행하는 메모리 공간을 별도로 할당음2-2-1. 기본 정렬 과정 -> 메모리의 소트 버퍼에 일부 데이터를 받아와 정렬 수행 -> 디스크에 임시로 기록 -> 다음 데이터를 받아와 소트 버퍼에서 정렬 수행 -> 디스크에 임시 기록 -> 반복 2-2-2. 소트 버퍼를 키우는 것은 도움이 되지 ..
인덱스를 지정하면, 인덱스는 b+tree구조로 디스크에 저장된다.1. 인덱스 키 값의 크기-> 인덱스의 노드는 {인덱스값, 페이지 주소}의 형태의 데이터들이 페이지로 형성되어 들어있다. -> 인덱스 값이 커지면, 한 페이지에 담을 수 있는 데이터들이 줄어듦 -> 즉, 인덱스 값이 커지면, 페이지가 많아지고, 그에 따라, 페이지를 갖고 있는 노드 증가 = b+tree의 깊이 또한 깊어질 가능성2. b+tree 깊이-> b+tree의 탐색 중 depth + 1은 랜덤 I/O를 의미한다. -> 당연히 랜덤 I/O가 많아지면 많아질수록 탐색의 시간은 길어진다.3. 기수성-> 기수성은 인덱스 값의 빈도를 뜻한다. 기수성이 크다 = 특정 값이 적게 나타난다. -> ex) select * from city where..
innodb에서 데이터를 찾는 방법들 **모든 리프 노드의 레코드 혹은 인덱스들은 논리적 순차 정렬되어있다. **물리적으로 깨질 수 있지만, 캐싱을 통해 논리적 정렬을 물리적 정렬처럼 효율을 관리할 수 있기 때문에 순차 I/O라고 볼 수 있다.1. 클러스터링 인덱스 스캔-> pk를 통해 검색 -> 조건에 인덱스가 갖고있는 정보가 없는 경우 인덱스 스캔 후, 클러스터링 인덱스 스캔이 필수적으로 발생1-1. 범위가 큰 경우(풀 테이블 스캔)-> b+tree 구조에서 depth+1 시 랜덤 I/O가 발생한다. -> 반면, 아예 리프 노드까지 들어가 전체 테이블을 순차 I/O로 탐색하는 방법도 있다. -> 즉, 범위가 크면 일일이 랜덤 I/O를 발생시키며 찾는 것 보다, 순차 I/O를 발생시키며 찾는 것이 낫다..
1. 글로벌 락FLUSH TABLES WITH READ LOCK => 하나의 세션이 이 락 권한을 획득하면 다른 모든 세션은 DDL, DML 등의 명령어 실행 금지=> 모든 테이블에 대해 flush가 가능해야한다. 즉, 현재 명령이 모두 끝나야 진행 가능=> 백업을 하려고, 서비스를 일시 정지하는 것은 매우 비효율적인 일이다.2. 백업 락LOCK INSTANCE FOR BACKUP;백업 로직UNLOCK INSTANCE; => DDL 명령어, DB 인증 관련 명령어 사용 불가=> 백업 락을 통해 서버 실행 중 백업 가능=======================================================1. 데이터 베이스 소스 서버, 레플리카 서버 준비2. 레플리카 서버 백업 락 걸기3. 소..
