WebMaster

데이터의 "내용" 자체에 대한 규칙은 어떻게 적용할까?상품의 가격(price)이나 재고 수량(stock_quantity)은 절대 음수일 수 없다.할인율(discount_rate)은 "0%"에서 "100%" 사이의 값이어야 한다.`NOT NULL` 제약 조건은 가격에 `-5000` 이라는 값이 들어오는 것을 막지 못한다. "UNIQUE" 제약 조건은 할인율이 "200"이 되는 것을 막지 못한다. 이런 값들은 형식적으로는 유효하지만, 비즈니스 논리상으로는 명백한 "쓰레기 데이터"다.이처럼 특정 컬럼에 들어갈 수 있는 값의 범위나 조건을 직접 지정하여, 한층 더 강화된 비즈니스 규칙을 적용하고 싶을때 사용하는 것이 바로 CHECK 제약 조건이다. CHECK 제약 조건의 역할과 문법"CHECK" 제약 조건은 ..

참조 무결성이란, 두 테이블의 관계가 항상 유효하고 일관된 상태를 유지해야 한다는 원칙이다. 예를 들어, orders 테이블의 user_id 컬럼은 반드시 users 테이블에 실제로 존재하는 "user_id" 값만을 참조해야 한다. 만약 존재하지도 않는 유령 회원의 주문이 있다면, 이 관계는 깨진 것이다. 이러한 테이블 간의 관계 무결성을 강제하는 가장 강력한 제약 조건이 바로 외래 키(Foreign Key)다. 외래 키(FK)의 역할: 유령 데이터를 막아라자식 테이블(orders)에 INSERT, UPDATE 할 때: 부모 테이블(users)에 존재하지 않는 "user_id" 값을 자식 테이블(orders)의 "user_id" 컬럼에 넣으려는 시도를 막는다. (유령 주문 생성 방지)부모 테이블(user..

NOT NULL: NULL 값 방지역할: 해당 컬럼에 NULL 값(값이 없는 상태)이 저장되는 것을 허용하지 않는다.반드시 필요한 정보가 누락되는 것을 막는다.문법 예시: "email VARCHAR(255) NOT NULL" "회원 가입 시 필수 정보인 이메일을 실수로 "NULL"로 입력하려고 시도해 보자.insert into users(name, email) values('냐옹이', null); insert into users(name, email) values('냐옹이', null) Error Code: 1048. Column 'email' cannot be null 0.00076 sec데이터베이스는 email 컬럼은 NULL일 수 없다는 명확한 에러 메시지를 반환하며, 이 INSERT 명령을 거부한..

데이터 무결성이 중요한 이유어느 날, 당신이 쇼핑몰의 월별 매출 보고서를 뽑았는데, 총매출액이 마이너스(-)로 나왔다고 상상해 보자. 황급히 원본 데이터를 살펴보니, 누군가의 실수 혹은 프로그램 버그로 인해 상품의 가격(price)에 "음수 값"이 들어가 있거나, 주문 수량(quantity)에 "-1"이 입력된 것을 발견했다. 또 다른 예로, 분명히 우리 쇼핑몰의 전체 고객은 "5명"인데, orders 테이블에는 존재하지도 않는 "user_id = 99번" 고객의 주문 기록이 남아있다. 이런 말도 안 되는 데이터, 현실 세계에서는 결코 존재할 수 없는 데이터를 우리는 "쓰레기 데이터(Garbage Data)"라고 부른다. 쓰레기 데이터가 초래하는 재앙잘못된 비즈니스 결정: 매출액이 음수로 찍힌 보고서를 ..

복합 인덱스 대원칙인덱스는 순서대로 사용하라! (왼쪽 접두어 규칙)등호(=) 조건은 앞으로, 범위 조건()은 뒤로!정렬(ORDER BY)도 인덱스 순서를 따르라! 인덱스는 순서대로 사용하라! 이는 "인덱스 왼쪽 접두어 규칙"을 의미한다. 복합 인덱스는 "(A, B, C)" 순서로 생성되었을 때, "WHERE" 절에서 A 조건 없이는 B나 C를 사용할 수 없다. 전화번호부에서 "성"을 모르고 "이름"만으로 사람을 찾을 수 없는 것과 같은 이치다.가능 (O): "WHERE A", "WHERE A AND B", "WHERE A AND B AND C"불가능 (X): "WHERE B", "WHERE C", "WHERE B AND C"이것이 복합 인덱스의 가장 기본적이고 절대적인 규칙이다.등호(=) 조건은 앞으로,..

범위 검색은 마지막에 한 번만 사용!이러한 제약 때문에 복합 인덱스를 설계할 때는 다음과 같은 순서를 따르는 것이 매우 중요하다. 등호(=) 조건을 사용하는 컬럼을 앞에, 범위 조건을 사용하는 컬럼을 뒤에 둔다. 예를 들어 아래의 쿼리가 자주 사용된다면?select * from items where category >= '패션' and price = 20000;최적의 인덱스는 순서를 변경해서 (price, category) 순서를 사용해야 한다.왜냐하면 "price = 20000"이라는 등호(=) 조건을 먼저 처리해서 검색 대상을 크게 줄일 수 있기 때문이다.(price, category) 순서의 인덱스를 추가하자create index idx_items_price_category_temp on items..

복합 인덱스 실패 예제1: 인덱스 순서 무시"카테고리와 상관없이 가격이 80,000원인 상품을 찾아보자."EXPLAIN SELECT * FROM items WHERE price = 80000;type(ALL): 풀 테이블 스캔이 발생했다.key(NULL): "idx_items_category_price" 인덱스가 있음에도 불구하고, 옵티마이저는 이 인덱스를 사용하지 않았다.왜 이런 결과가 나왔을까? 인덱스 왼쪽 접두어 규칙 때문이다. "idx_items_category_price" 인덱스는 category로 먼저 정렬되어 있다. price가 "80000"인 상품은 '전자기기' 카테고리에도 있을 수 있고, 만약 있다면 '패션' 카테고리에도 있을 수 있다. 즉, "price" 값은 인덱스 전체에 흩어져 있다..

인덱스는 공짜가 아니다( 인덱스의 단점)저장 공간 (Storage)인덱스는 원본 테이블과는 별개로, B-Tree 구조를 가진 물리적인 파일로 디스크에 저장된다.즉, 인덱스를 생성하면 그만큼의 추가 저장 공간이 필요하다.인덱스는 어떻게 구성하는지에 따라 다르지만, 일반적으로 원본 테이블 크기의 약 10% 내외의 공간을 추가로 차지한다고 알려져 있다. 만약 100GB에 달하는 거대한 items 테이블이 있고, 여기에 5개의 인덱스를 추가로 생성한다면? 인덱스만으로 약 50GB라는 무시할 수 없는 추가 디스크 공간이 필요하게 된다. 인덱스를 무분별하게 생성하면 디스크 사용량이 계속해서 늘어나는 것을 보게 될 것이다. 쓰기 성능 (INSERT, UPDATE, DELETE)인덱스는 "SELECT"의 속도를 높이는..

인덱스를 만드는 법(CREATE INDEX)을 아는 것보다 더 중요한 것은, 어디에 인덱스를 만들어야 하는지 아는 것이다. 잘못된 인덱스는 오히려 시스템 성능을 떨어뜨리는 애물단지가 될 수 있다 인덱스는 결코 공짜가 아니다. 데이터를 추가(INSERT), 수정(UPDATE), 삭제(DELETE)할 때마다 인덱스도 함께 변경되어야 하므로 쓰기 성능이 저하되고, 별도의 저장 공간도 차지한다. 따라서 우리는 이 비용을 상쇄하고도 남을 만큼의 "검색 성능 향상"이라는 이득을 얻을 수 있는 곳에만 전략적으로 인덱스를 생성해야 한다. 핵심 원칙: 카디널리티 (Cardinality)인덱스를 어디에 걸지 판단하는 가장 중요한 기준은 바로 카디널리티(Cardinality)다. 카디널리티란, 해당 컬럼에 저장된 값들의 고..

"카테고리가 '전자기기'인 상품들 중에 가격이 100,000원 이상인 상품을 보여줘" 이러한 요구사항이 들어왔다.SELECT * FROM itemsWHERE category = '전자기기' AND price >= 100000 다중 조건 쿼리의 성능을 최적화하기 위해 사용하는 것이 바로 복합 인덱스(Composite Index) 또는 다중 컬럼 인덱스(Multi-column Index)다.복합 인덱스는 이름 그대로 두 개 이상의 컬럼을 묶어서 하나의 인덱스로 만드는 것이다하지만 복합 인덱스를 제대로 사용하려면 한 가지 매우 중요한 규칙을 이해해야 한다. 바로 "컬럼의 순서"다왜 컬럼 순서가 중요할까?복합 인덱스의 동작 원리는 우리가 실생활에서 사용하는 "전화번호부"나 "국어사전"과 똑같다.전화번호부: "..