인덱스 수직적 탐색 정렬된 인덱스 레코드 중 조건을 만족하는 첫 번째 레코드를 찾는 과정 즉 인덱스 스캔 시작 지점을 찾는 과정 인덱스 수평적 탐색 수직적 탐색으로 찾은 스캔 시작점에서 찾고자 하는 데이터가 더 안 나타날 때까지 수평적으로 스캔하는 과정 즉 실제로 데이터를 찾는 과정 WHERE 절의 조건 순서에 따라서 성능이 결정된다? 잘못된 정보임. 비교 연산 횟수를 줄일 수 있다는 설명은 맞음. 하지만 인덱스의 자료구조인 B+Tree는 평면 구조가 아님. 어떤 순서로 해도 일 량에는 차이가 없음. (자세한 건 인덱스 성별 여자 이름 유관순으로 검색해볼 것, 대부분이 잘못된 자료인 경우라고 함) 인덱스를 RANGE SCAN 할 수 없는 이유 1. 인덱스 칼럼을 가공하면 인덱스를 정상적으로 사용할 수 없..

SQL의 성능을 결정하는 디스크 I/O 1. I/O를 처리하는 동안 프로세스는 잠을 잔다. 2. 즉 프로세스가 디스크에서 데이터를 읽어야 할 때, CPU는 OS에 반환하고 잠시 waiting state 상태로 진입해 I/O가 완료되길 기다린다. 즉 프로세스가 I/O가 많을수록 대기시간이 길어지고 성능이 느려진다. 3. 아무리 하드웨어 성능이 향상되고 있지만 여전히 느리다. 그러므로 디스크 I/O를 줄이기 위한 최적화가 필요하다. SQL의 데이터 구조 1. 블록: 데이터를 읽고 쓰는 단위 2. 익스텐트: 공간을 확장하는 단위, 연속된 블록 집합 3. 세그먼트: 데이터 저장공간이 필요한 오브젝트(테이블, 인덱스, 파티션, LOB 등) 4. 테이블 스페이스: 세그먼트를 담는 컨테이너 5. 데이터 파일: 디스크..

소프트 파싱 vs 하드 파싱 1. SQL 파싱, 최적화, 로우 소스 생성 과정을 거쳐 생성한 내부 프로시저를 반복 재사용할 수 있도록 캐싱해 두는 메모리 공간을 라이브러리 캐시(Library Cache)라고 한다. 2. 라이브러리 캐시는 SGA(System Global Area)의 구성요소다. SGA는 서버 프로세스와 백그라운드 프로세스가 공통으로 액세스 하는 데이터와 제오 구조를 캐싱하는 메모리 공간이다. 3. SQL문을 전달하면 DBMS는 파싱 후 해당 SQL이 라이브러리 캐시에 있는지 확인한다. 캐시에 있으면 곧바로 실행 단계로 넘어가지만 캐시 미스가 발생하면 최적화 단계를 거친다. 소프트 파싱 --> 라이브러리 캐시에 SQL이 존재해서 바로 실행단계로 넘어가는 과정 하드 파싱 --> 라이브러리 캐..

SQL 최적화 1. SQL 파싱 사용자로부터 SQL을 전달받으면 가장 먼저 SQL 파서(Parser)가 파싱을 진행한다. 파싱 순서 1. 파싱 트리 생성: SQL문을 이루는 개별 구성요소를 분석해서 파싱 트리 생성 2. Syntax 체크: 문법적 오류가 없는지 확인, 예를 들어 사용할 수 없는 키워드를 사용했거나 순서가 바르지 않거나 누락된 키워드가 있는지 확인 3. Semantic 체크: 의미상 오류가 없는지 확인, 예를 들어 존재하지 않는 테이블 또는 칼럼을 사용했는지, 사용한 오브젝트에 대한 권한이 있는지 확인 2. SQL 최적화 옵티마이저(Optimizer)가 역할하는 단계. 옵티마이저는 미리 수집한 시스템 및 오브젝트 통계정보를 바탕으로 다양한 실행 경로를 생성해서 비교한 후 가장 효율적인 하나..

NoSQL SQL 쿼리는 다음과 같은 단계를 거친다 1. 쿼리의 수신 2. 구문 해석 3. 테이블의 오픈 4. 테이블의 잠금 5. 실행 계획의 작성 6. 레코드로의 액세스 7. 테이블의 잠금 해제 8. 테이블의 클로즈 9. 결과 회신 기본 키 검색이라는 용도로 사용할 때 실제로 애플리케이션에서 의미가 있는 작업은 1,6,9번 밖에 없다. 그 이외의 작업은 모두 불필요한 작업이다. 이 불필요한 작업 때문에 데이터베이스의 성능을 발목 잡는다. NoSQL은 이런 관점에서 MySQL 보다 약 3배 이상의 빠른 쿼리 처리량을 보여준다. 탄생 배경 기본키 이용한 단순 검색 같은 경우처럼... SQL문과 같은 복잡한 언어를 사용하지 않고 프로그래밍 언어의 라이브러리 함수를 사용하여 직접 데이터를 액세스 하는 편이 훨..