just-data

SQL에서 집계 함수를 사용할 때 자주 쓰이는 함수가 있습니다. 바로 HAVIN문입니다. 하지만 무분별한 사용은 성능 저하를 초래할 수 있기 때문에, HAVING을 꼭 써야 하는 경우가 아니라면 WHERE문으로 대체하는 것이 더 바람직한 경우가 많습니다. 이번 글에서는 100만 건의 데이터를 기반으로 HAVING을 사용했을 때와 WHERE으로 대체했을 때의 성능 차이를 비교해 보며, 어떤 방식이 더 효율적인지 실습을 통해 확인해 보겠습니다. 실습CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100), age INT, department VARCHAR(100), salary INT, created..

SQL 최적화에서 자주 나오는 고민 중 하나는 WHERE 절에 인덱스를 거는 게 좋은지, 아니면 ORDER BY 절에 인덱스를 거는 게 좋은지에 대한 문제입니다. 정답은 하나가 아닙니다. 데이터의 구조, 쿼리의 목적, 그리고 실행 계획에 따라 달라질 수 있기 때문입니다. 이번 글에서는 실제 100만 건의 데이터를 바탕으로 각각의 경우를 비교하고, 어떤 인덱스 전략이 더 효율적인지 실행 시간과 실행 계획을 통해 확인해 보겠습니다. 실습CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100), department VARCHAR(100), salary INT, created_at TIMESTAMP DEFAU..

정렬(ORDER BY)은 비싼 작업입니다MySQL에서 ORDER BY는 생각보다 성능 비용이 큰 연산입니다.특히 데이터가 많을수록 정렬에 드는 리소스는 기하급수적으로 늘어나기 때문에 최대한 정렬 작업을 피하거나, 미리 정렬된 상태에서 데이터를 가져오는 방식으로 바꾸는 것이 핵심입니다. 이번 글에서는 ORDER BY와 LIMIT 조합에서 인덱스를 어떻게 활용하면 성능을 개선할 수 있는지 실습을 통해 살펴보겠습니다. 실습CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100), department VARCHAR(100), salary INT, created_at TIMESTAMP DEFAULT CURREN..

MySQL에서 인덱스를 걸어도 예상과 달리 EXPLAIN 결과에 Full Table Scan이 찍히는 경우가 있습니다.“인덱스를 걸었는데 왜 작동하지 않지?”라는 의문이 드는 순간, 우리는 쿼리 작성 방식을 돌아봐야 합니다. 이번 글에서는 실제 인덱스를 무력화되는 대표적인 상황을 실습을 통해 알아보고, 어떻게 쿼리를 고쳐야 인덱스를 제대로 활용할 수 있는지 소개합니다. Case 1CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100), age INT);SET SESSION cte_max_recursion_depth = 1000000;INSERT INTO users (name, age)WITH RECURSIVE ..

SQL의 WHERE 조건은 단순히 필터 역할을 넘어 쿼리 성능의 핵심 요소입니다.특히, 조건절에 어떤 컬럼이 들어가느냐, 그리고 그 컬럼에 인덱스가 있느냐에 따라 쿼리 속도가 수배에서 수십 배까지 차이 날 수 있습니다. 이번 글에서는 WHERE절 조건을 중심으로 SQL 튜닝 실습을 진행해보겠습니다. 실습: Sales 부서이면서 최근 3일 이내에 가입한 유저 조회데이터셋 준비CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100), department VARCHAR(100), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP);-- 100만 건 더미 데이터 생성SET SESSI..

너무 많은 데이터를 한 번에 조회하면 어떻게 될까?데이터베이스에서 데이터를 빠르게 조회하기 위해 많은 노력을 들이지만, 기본적으로 꼭 먼저 점검해야 할 것이 하나 있습니다. 바로 다음과 같은 질문입니다."이 쿼리에서 한 번에 너무 많은 데이터를 조회하고 있는 건 아닐까?" 실제로 많은 데이터가 들어 있는 테이블에서 한 번에 수천, 수만 건의 데이터를 불러오면 성능은 금방 저하되며, 사용자 경험도 떨어지게 됩니다. 실습: 조회 데이터 개수에 따른 성능 차이1. 실습 테이블 생성CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100), age INT);SET SESSION cte_max_recursion_depth =..

실행 계획이란?MySQL에서 SQL문을 실행하면, 옵티마이저(optimizer)가 쿼리를 가장 효율적으로 수행할 수 있는 방식으로 실행 계획을 수립합니다.이때 생성되는 실행 경로를 실행 계획(Execution Plan)이라고 합니다.실행 계획을 분석하면 다음과 같은 내용을 파악할 수 있습니다.어떤 인덱스를 사용하는지얼마나 많은 데이터를 읽는지테이블을 어떤 방식으로 접근하는지이러한 실행 계획을 확인하면, 비효율적인 쿼리를 진단하고 개선할 수 있는 기회가 생깁니다. 실행 계획은 아래와 같은 코드를 통해 확인할 수 있습니다.-- 기본 실행 계획 조회EXPLAIN [SQL문];-- 실제 실행 시간까지 포함해서 확인 (MySQL 8.0 이상)EXPLAIN ANALYZE [SQL문]; 예시 테이블을 생성 후 확인..

커버링 인덱스란?MySQL에서 인덱스는 보통 필터링과 정렬을 빠르게 하기 위해 사용됩니다.하지만 인덱스가 하는 일은 거기서 끝나지 않습니다.인덱스만으로도 SQL의 결과를 바로 조회할 수 있다면 훨씬 빠르게 쿼리를 처리할 수 있습니다.이처럼,SQL 실행에 필요한 모든 컬럼이 인덱스에 포함되어 있어, 테이블(데이터 영역)에 접근하지 않아도 되는 인덱스를우리는 커버링 인덱스(Covering Index) 라고 부릅니다. 커버링 인덱스를 왜 쓰는가?간단합니다.인덱스에만 접근하면 되므로 속도가 빠릅니다.테이블 데이터까지 내려가서 가져오는 I/O를 줄일 수 있습니다.결과적으로 디스크 접근량 감소 → 실행 속도 개선으로 이어집니다.예시로 이해해보겠습니다. 아래는 users 테이블입니다. id name create..

멀티 컬럼 인덱스란?멀티 컬럼 인덱스란, 2개 이상의 컬럼을 묶어서 만든 인덱스를 말합니다.즉, 단일 컬럼이 아니라 두 개 이상의 컬럼을 기준으로 정렬된 탐색용 자료구조라고 이해하면 됩니다.보다 직관적으로 표현하자면,여러 컬럼을 기준으로 데이터를 미리 정렬해놓은 표가 멀티 컬럼 인덱스입니다. CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, 이름 VARCHAR(100), 부서 VARCHAR(100), 나이 INT);INSERT INTO users (이름, 부서, 나이) VALUES('박미나', '회계', 26),('김미현', '회계', 23),('김민재', '회계', 21),('이재현', '운영', 24),('조민규', '운영', 2..

SQL 인덱스는 조회 성능을 높여주는 강력한 도구입니다.그래서 많은 분들이 이렇게 생각하곤 합니다."그럼 자주 사용할 만한 컬럼엔 전부 인덱스를 걸면 되는 거 아냐?"하지만 현실은 다릅니다.인덱스는 조회 성능을 높여주는 대신, 쓰기 작업(삽입, 수정, 삭제) 성능을 떨어뜨립니다. 인덱스가 많아지면 성능이 왜 느려질까?인덱스를 생성한다는 것은 단순히 "검색이 빨라진다"는 의미가 아닙니다.인덱스를 위한 내부 자료 구조(B-tree)가 함께 관리되기 때문에, 데이터를 삽입하거나 수정할 때마다 MySQL은 원본 테이블뿐만 아니라 인덱스 테이블까지 함께 갱신해야 합니다. 즉, 인덱스의 개수가 많을수록 쓰기 작업 시 처리해야 할 작업량도 늘어나게 되는 것입니다. 실제로 인덱스가 없는 테이블과 인덱스가 많은 테이블 ..