ballde

인덱스가 만약 많다면? DML 성능 저하 - TPS 저하 데이터 베이스 사이즈 증가 데이터베이스 관리 및 운영 비용 증가 ⇒ 개별 쿼리 성능뿐만 아니라 그 개수를 최소화함으로써 DML 부하를 줄여야 하므로 인덱스 설계가 어렵다. ⇒ 그리고 인덱스 추가는 시스템에 부하를 주고 인덱스 변경은 운영에 리스크가 있기 때문에 처음 설계가 중요하다. 인덱스 선택 조건절에 항상 사용하거나 자주 사용하는 컬럼 ‘=’ 조건으로 자주 조회되는 컬럼을 앞쪽에 두어야한다. 수행빈도, 중요도, 데이터량 등 .. nl 조인할 때 어느쪽에서 자주 액세스 되는지도 중요한 판단 기준이 된다. ⇒ 이후에 nl조인에서 설명함 수행빈도가 높다면 당장 성능이 좋아도 인덱스를 최적으로 구성해야한다. 데이터량이 적다면 굳이 인덱스를 만들 필요가..

💡 운영 환경에서 가능한 일반적인 튜닝 기법은 인덱스 컬럼 추가 인덱스 탐색과정에 대해서 알아보자 루트 블록에서 LMC는 자식 노드 중에서 가장 왼쪽 끝에 위치한 블록을 가리킨다. 주의할 점이 C1 = ‘B’인 레코드를 찾을 때 리프블록 3으로 가는 것이 아닌 직전 리프블록 2로 가야한다. 각 조건절에 대해서 원리를 설명하기. where C1 = 'B' where C1 = 'B' and C2 = 3 where C1 = 'B' and C2 >= 3 where C1 = 'B' and C2 = 'a' where c1 = 1 and c2 = 'A' and c3 between '가' and '다' and c4 = 'a' where c1 = 1 and c2

부분범위 처리 DBMS가 클라이언트에게 데이터를 전송할 때 일정량씩 나누어 전송한다. 전송한 후에 fetch call이 있기 전까지 기다린다. 1억건짜리 테이블인데도 결과를 빨리 출력할 수 있는 이유 한번에 데이터를 모두 읽어 전송하지 않고 먼저 읽는 데이터부터 일정량을 전송하고 멈추기 때문이다. fech call을 받으면 대기 큐에서 나와 그 다음 데이터부터 일정량을 읽어서 전송하고 또다시 잠을 잔다. ⇒ 부분 범위 처리 - 약간 페이징하고 원리가 비슷한듯 정렬 조건이 있을 때 부분 범위 처리 select * from user order by created 인덱스가 안되어 있다면? 모든 데이터를 읽고 created 순으로 정렬 데이터 전송 인덱스가 되어 있다면? 이미 정렬되어 있으므로 부분범위 처리가 ..

인덱스 ROWID 인덱스는 스캔한 후에 반드시 테이블을 액세스한다. 인덱스를 스캔하는 이유 검색 조건을 만족하는 소량의 데이터를 인덱스에서 빨리 찾고 거기서 테이블 레코드를 찾아가기 위한 주소값(rowId)를 얻기 위함이다. 여기서 rowId는 물리적 주소라고 할 수도 있지만 논리적 주소에 가깝다. ⇒ 테이블 레코드를 찾아가기 위한 위치 정보를 담는다. (물리적으로 포인터 처럼 위치를 가리키는게 아님) 메인 메모리 DB와의 비교 메인메모리란 메모리를 통해서만 I/O를 통해서 수행하는 DB이다. ⇒ 메인 메모리는 포인터를 가지고 있어 엄청 빠르다. 하지만 우리가 흔히 사용하는 DB들은 수시로 버퍼캐시에서 밀려났다가 다시 캐싱되고 그때마다 다른 주소로 캐싱되기 때문에 포인터로 직접 연결할 수 없는 구조로 메..

💡 index full scan, index unique scan, index skip scan, index fast full scan Index range scan 핵심은 필요한 범위만 스캔한다. 컬럼 가공 X 인덱스 스캔 범위, 테이블 액세스 횟수를 얼마나 줄일 수 있느냐 index full scan 인덱스 리프 블록을 처음부터 끝까지 수평적으로 탐색한다. 데이터 검색을 위한 최적의 인덱스가 없을 때 차선으로 선택한다. 인덱스 선두컬럼이 아닌것은 index range scan이 불가능 효용성 인덱스 선두 컬럼이 조건절에 없으면 table full scan 고려 index range scan이 불가능 할 떄 면적이 넓은 테이블을 스캔하는 것보다 면적이 작은 인덱스를 full scan하는 것이 좋기 때문..

인덱스를 사용한다는 것 인덱스를 정상적으로 사용한다 라는 표현은 리프 블록에서 스캔 시작점을 찾아 거기서부터 스캔하다가 중간에 멈추는 것을 의미합니다. ⇒ index range scan 인덱스 컬럼을 가공해도 인덱스를 사용할 수 있지만 스캔 시작점을 찾을 수 없고 멈출 수 없어리프 블록 전체를 스캔해야한다. ⇒ index full scan 그렇다면 index range scan을 할 수 없는 이유는? 시작점을 찾을 수 없기 때문이다. 예시 where 생년월일 between '20070101' and '20070131' 위 예시는 시작점과 끝 지점을 알 수 있다. where substr(생년월일, 5, 2) = '05' 위 예시는 시작점과 끝 지점을 알 수 없다. nvl(ifnull), like, or 등..

💡 핵심 원리를 알아보자 인덱스 튜닝의 두 가지 핵심 요소 인덱스 스캔 효율화 튜닝 랜덤 액세스 최소화 튜닝(테이블 액세스 횟수를 줄이는 것) ⇒ 이것이 중요!! 인덱스 구조 대용량 테이블에서 필요한 데이터만 빠르게 효율적으로 액세스하기 위해 사용하는 오브젝트 (책에 있는 색인 느낌!) 인덱스가 없다면? 테이블을 처음부터 끝까지 모두 읽어야합니다. 인덱스를 사용한다면? 일부만 읽고 멈춘다. ⇒ 범위 스캔 인덱스가 사용하는 알고리즘은? B-트리 일반적으로 DBMS에서는 주로 B+-Tree 또는 B*-Tree가 사용된다. 주의할 점이 B는 binary(이진)이 아닌 Balanced 입니다. insert 작업 또는 delete 작업을 할 때 인덱스가 불균형 상태에 놓일 수도 있을거라고 생각을 하게 되는데 B*..

SQL이 느린 이유 결론은 I/O 때문이다. 프로그램 즉 여러 프로세스가 하나의 cpu를 공유하고 특정 순간에는 하나의 프로세스만 cpu를 사용하기 때문에 준비시간이 필요하다. ⇒ I/O콜이 많아지면 디스크 경합이 많아지고 대기시간이 늘어나고 성능이 느릴수밖에 없다. 데이터 저장 구조 테이블 스페이스 - 세그먼트 - 익스텐트 - 블록 - 그안에 로우들이 있다. 세그먼트 세그먼트는 테이블, 인덱스처럼 데이터 저장공한이 필요한 오브젝트 익스텐트 공간을 확장하는 단위 블록(mysql 에서는 page) 사용자가 입력한 레코드를 실제로 저장하는 공간 // oracle select segment_type, tablespace_name, extent_id, file_id, block_id, blocks from db..

💡 소프트 파싱과 하드 파싱의 차이점 소프트 파싱 vs 하드 파싱 SGA(system global area)란?(오라클에서) 먼저 라이브러리 캐시에 존재하는지 확인 존재하면 실행 단계로 넘어감 (소프트 파싱) 존재하지 않으면 최적화 (하드 파싱) ⇒ 하드라고 하는 이유는 최적화 자체가 매우 무겁고 복잡하기 때문에 Buffer Pool(oracle 의 sga와 비슷한 개념) 버퍼 풀은 InnoDB가 액세스 할 때 테이블 및 인덱스 데이터를 캐시하는 메인 메모리 영역 바인드 변수의 중요성 # 프로시저, 트리거, 패키지 등은 이름이 있다. => A create procedure A() {} # sql은 텍스트가 이름 역할 select * from store SELECT * from store 파라미터 Driv..

SQL과 옵티마이저 sql은 구조적이고 집합적이고 선언적인 질의 언어입니다. ⇒ 선언을 해서 결과를 받아오는데 이 과정에서 쿼리를 최적으로 실행하기 위해 각 테이블의 데이터가 어떤 분포로 저장돼 있는지를 참조하고, 데이터를 기반으로 최적의 실행계획을 수립해주는 것이 옵티마이저입니다. SQL 최적화 과정 세분화 SQL 파싱 - sql 파서가 파싱을 진행합니다. 파싱 트리 생성 - sql문을 이루는 개별 구성요소를 분석해서 파싱 트리를 생성 Syntax 체크 - 문법적 오류가 없는지를 확인 semantic 체크 - 의미상 오류가 없는지 체크 sql 최적화 - 옵티마이저가 역할을 맡음 다양한 실행경로를 생성해서 비교한 후 가장 효율적인 하나를 선택합니다. - DB 성능의 핵심 로우 소스 생성 sql 옵티마이저..