DB (27) 썸네일형 리스트형 [DB] 인덱스 느린 검색의 원인 - 풀 테이블 스캔 (Full Table Scan)인덱스가 없는 테이블에서 특정 데이터를 찾는 과정은, 비유하자면 100만 페이지짜리 거대한 책에서 특정 단어 하나를 찾기 위해, 책의 첫 페이지부터 마지막 페이지까지 한 장 한 장 넘겨보는 것과 같습니다. 예를 들어, 인프런의 데이터베이스에는 '강의 목록 ' 컬럼이 존재하고 이 컬럼에 '김영한의 실전 데이터베이스 강의 ' 이라는 값이 어디에 있는지 알 수 있는 아무런 힌트가 없습니다. 그래서 데이터베이스는 가장 무식하고 정직한 방법을 선택한다고 합니다. 그것은 바로 테이블 전체를 디스크에서 메모리로 읽어들인 후, 첫 번째 행부터 마지막 100만 번째 행까지 하나씩 차례대로 '강의 목록 ' 컬럼의 값을 비교하는 것 입니다. 이러한 작업.. [DB] 클러스터드 vs 넌클러스터드 인덱스 📌 클러스터드 인덱스 (Clustered Index)실제 데이터가 인덱스 순서대로 정렬되어 저장됩니다.즉, 인덱스 자체가 데이터입니다.한 테이블에 하나만 존재 가능 (정렬이 하나 기준이니까)✅ 장점범위 조회에 빠름 (BETWEEN, ORDER BY)접근 시 디스크 I/O가 줄어듦❌ 단점데이터 삽입/삭제 시 정렬 유지해야 하므로 성능 저하 가능한 테이블당 하나만 가능 📌 넌클러스터드 인덱스 (Non-Clustered Index)인덱스와 실제 데이터가 분리되어 있음인덱스에는 데이터의 포인터만 저장되어 있고, 필요한 값은 본문에서 추가로 읽음 (lookup)✅ 장점다양한 컬럼에 여러 개 생성 가능클러스터드 인덱스 외 다른 조건도 최적화 가능❌ 단점인덱스로 찾고 → 다시 테이블 접근 (lookup) 필요해서.. [DB] 옵티마이저 동작 방식 🤔 DB 옵티마이저란?DB 옵티마이저는 SQL 쿼리를 가장 효율적으로 실행할 실행 계획 (Execution Plan)을 선택하는 역할을 한다. 이걸 선택하는 방식에는 두 가지가 있다. 규칙 기반 옵티마이저 (Rule-Based Optimizer, RBO)데이터 통계 정보 를 고려하지 않고, 정해진 규칙(rule)을 기반으로 실행 계획을 선택합니다. 예시인덱스가 있으면 무조건 인덱스를 사용한다조인 순서는 항상 왼쪽부터 처리특징예측 가능하고 단순함데이터 양이 많아지면 비효율적인 계획이 나올 수 있다.실제 상황에 맞는 유연한 선택을 못한다. 비용 기반 옵티마이저 (Cost-Based Optimizer, CBO)각 실행 계획마다 예상 비용(cost)을 계산해서 가장 저렴한 걸 선택합니다.통계 정보 (행 수, .. [DB] 드라이빙, 드라이븐 테이블 🤔 드라이빙 테이블?먼저 읽기 시작하는 테이블이다.이 테이블의 결과를 기반으로, 다른 테이블(드라이븐 테이블)을 조건에 따라 탐색한다.루프의 바깥쪽 테이블 이라고 생각하면 된다.🤔 드라이븐 테이블?드라이빙 테이블에서 가져온 각 행을 기준으로 탐색되는 두 번째 테이블이다.루프의 안쪽 테이블 이다.드라이빙 테이블의 값을 이용해서 조인 조건을 만족하는 행을 찾는 대상이다.🤔 왜 중요할까?조인의 성능은 드라이빙 테이블의 선택 에 크게 영향을 받는다.👉 드라이빙 테이블이 작고 조건이 잘 걸리는 테이블일수록 효율적이다.예시: Orders가 수십만 개고 Customers가 수천 명일 때,SELECT *FROM Orders oJOIN Customers c ON o.customer_id = c.idWHERE c... [DB] 조인 전략 🔗 Join 전략DB에서 여러 테이블을 연결할 때 사용하는 방식이다.어떻게 두 테이블을 매칭하고 결과를 만들 것인지에 따라 전략이 나뉜다. 🔁 Nested Loop Join가장 기본적인 방식이다. 말 그대로 반복문 안에 반복문.한 테이블의 데이터를 하나씩 꺼내서, 다른 테이블을 전부 뒤져서 매칭한다.작은 테이블 + 인덱스가 있을 때 효과적느리다 (두 테이블 모두 클 경우 O(N²))예시SELECT *FROM Employees eJOIN Departments d ON e.dept_id = d.id;Employees의 각 직원마다 Departments 전체를 검색해서 일치하는 id를 찾음📊 Hash Join작은 테이블을 해시맵(키-값 쌍)처럼 메모리에 저장한 뒤, 큰 테이블에서 값을 하나씩 비교해시 테.. [DB] 데이터베이스에서 사용되는 다양한 키 🔑 1. 기본 키 (Primary Key)테이블에서 각 레코드를 고유하게 식별하는 데 사용된다.또한, 후보 키들 중에서 하나를 선택해서 지정한 유일한 키이다.CREATE TABLE employees ( id INT PRIMARY KEY, -- 기본 키 name VARCHAR(50), salary INT); ✅ 특징유일성: 기본 키의 값은 중복될 수 없음.널 값 불허: 기본 키는 널 값(NULL)을 가질 수 없음.기본 키가 설정된 컬럼은 자동으로 인덱스가 생성된다.2. 유니크 키 (Unique Key)기본 키와 유사하지만, 중복된 값은 허용하지 않지만 NULL 값은 허용된다.CREATE TABLE users ( user_id INT PRIMARY KEY, email VARCHA.. [DB] MySQL InnoDB의 인덱스 생성 전략 📌 1. 기본키 인덱스 (Primary Key Index)기본키(PK)가 설정된 컬럼에 자동으로 생성되는 인덱스이다.InnoDB에서는 기본키가 클러스터형 인덱스(Clustered Index)로 동작한다.데이터가 기본키 기준으로 물리적으로 정렬되며 저장된다.✅ 특징테이블당 하나의 기본키만 설정 가능하다.NULL을 허용하지 않으며, 중복된 값을 가질 수 없음.기본키 검색이 빠르며, 다른 인덱스에서 기본키를 사용해 데이터 검색을 수행함.🚀 예제CREATE TABLE employees ( id INT PRIMARY KEY, name VARCHAR(100));위와 같이 id를 기본키로 설정하면, id를 기준으로 클러스터형 인덱스(Clustered Index)가 생성된다.📌 2. 클러스터형 인덱스.. [CS] 데드락 데드락(교착 상태)두 개 이상의 프로세스 혹은 쓰레드가 서로가 가진 리소스를 기다리는 상태 데드락을 만드는 네 가지 조건상호 배제(Mutual exclusion): 리소스를 공유해서 사용할 수 없다.점유와 대기(hold and wait): 프로세스가 이미 하나 이상의 리소스를 취득한 상태(hold)에서 다른 프로세스가 사용하고 있는 리소스를 추가로 기다린다(wait).비선점(No preemption): 리소스 반환은 오직 그 리소스를 취득한 프로세스만 할 수 있다.원형 대기(Circular wait): 프로세스들이 순환하는 형태로 서로의 리소스를 기다리는 상태운영체제(OS)의 데드락 해결 방법데드락 방지데드락 회피데드락 감지와 복구데드락 무시데드락 방지(Deadlock prevention)네 가지 조건 .. 이전 1 2 3 4 다음
