API를 만들었는데 데이터를 가져오는 쿼리가 원하는 결과를 반환하지 않습니다. WHERE 조건이 맞는 것 같은데 데이터가 안 나오거나, ORDER BY 없이 매번 순서가 달라집니다. SELECT 구조와 각 절의 실행 순서를 정확히 이해해야 원하는 데이터를 정확하게 조회할 수 있습니다.

확대

기본 SELECT 구조

SELECT 문은 다음 절들을 순서대로 조합해서 사용합니다. FROM으로 대상 테이블을 지정하고, WHERE로 조건을 걸고, ORDER BY로 정렬하고, LIMIT/OFFSET으로 결과 수를 제한합니다.

논리적 실행 순서 — 작성 순서와 다르다

DB는 SQL을 쓴 순서대로 실행하지 않습니다. 논리적 실행 순서는 다음과 같습니다:

FROM/JOIN  →  WHERE  →  GROUP BY  →  HAVING  →  SELECT  →  ORDER BY  →  LIMIT/OFFSET
(테이블 결정) (행 필터) (그룹화)   (그룹 필터) (열·별칭) (정렬)     (개수 제한)

이 순서가 실무 함정을 설명합니다:

• WHERE에서 SELECT 별칭(alias)을 못 쓴다 — WHERE가 SELECT보다 먼저 실행되어 별칭이 아직 없기 때문. 그룹 조건은 WHERE가 아니라 HAVING으로.
• LIMIT은 "맨 마지막" — 정렬(ORDER BY)까지 끝난 결과에서 N개를 자릅니다. LIMIT 10은 "100ms 안에 10개"가 아니라 "정렬된 결과의 상위 10행"이라는 뜻(성능과 무관한 행 개수 제한).
• ORDER BY 없는 LIMIT은 무의미 — 정렬이 없으면 어떤 10개가 나올지 보장되지 않습니다(매 실행마다 달라질 수 있음).

SELECT 컬럼명1, 컬럼명2
FROM 테이블명
WHERE 조건
ORDER BY 정렬컬럼 ASC
LIMIT 최대행수
OFFSET 건너뛸행수;

실행 완료 또는 조회 결과가 표시됩니다.

WHERE 조건 연산자

WHERE 절에는 다양한 연산자를 조합할 수 있습니다. 아래 표는 자주 쓰는 연산자를 정리한 것입니다.

BETWEEN은 경계값을 포함합니다. BETWEEN 10000 AND 50000은 >= 10000 AND <= 50000과 동일합니다.

LIKE 와일드카드에서 %는 0개 이상의 문자, _는 정확히 한 글자를 의미합니다. 앞에 %가 붙는 패턴('%gmail.com')은 인덱스를 사용할 수 없어 대형 테이블에서 성능 문제가 생깁니다. 접두사 검색('김%')은 인덱스를 활용할 수 있습니다.

NOT IN은 목록에 NULL이 포함되어 있으면 예상치 못한 결과를 반환합니다. NULL과의 비교는 항상 UNKNOWN이 되기 때문입니다.

SELECT * FROM products WHERE price = 10000;
SELECT * FROM products WHERE price BETWEEN 10000 AND 50000;
SELECT * FROM orders WHERE status IN ('pending', 'processing', 'shipped');
SELECT * FROM users WHERE email LIKE '%@gmail.com';
SELECT * FROM users WHERE name LIKE '김%';
SELECT * FROM users WHERE name LIKE '_길동';
SELECT * FROM products
WHERE category = '전자제품'
  AND price < 100000
  AND stock > 0;
SELECT * FROM users
WHERE (role = 'admin' OR role = 'moderator')
  AND deleted_at IS NULL;

SELECT 실전 예시

아래는 실무에서 자주 쓰이는 SELECT 패턴 5가지입니다. AS 키워드로 컬럼에 별칭을 붙이고, DISTINCT로 중복을 제거하고, LIMIT/OFFSET으로 페이지네이션을 구현합니다. 페이지네이션에서 3페이지(페이지당 20개)를 조회하려면 OFFSET은 (페이지-1) * 페이지크기 = 40이 됩니다.

SELECT id, name, email, created_at
FROM users
WHERE deleted_at IS NULL
ORDER BY created_at DESC
LIMIT 10;

SELECT
    id,
    name AS 상품명,
    price AS 가격,
    ROUND(price * 0.9, 0) AS 할인가
FROM products
WHERE is_active = true
ORDER BY price DESC
LIMIT 20;

SELECT DISTINCT category
FROM products
WHERE is_active = true
ORDER BY category;

SELECT id, name, price
FROM products
ORDER BY id
LIMIT 20 OFFSET 40;

SELECT *
FROM orders
WHERE created_at >= '2024-01-01'
  AND created_at < '2024-02-01'
ORDER BY created_at DESC;

ORDER BY 정렬

여러 컬럼으로 정렬할 때는 앞에 나온 기준이 먼저 적용됩니다. 아래 예시에서 가격이 같은 상품끼리는 이름 오름차순으로 추가 정렬됩니다.

SELECT * FROM products ORDER BY price ASC;
SELECT * FROM products ORDER BY price DESC;

SELECT * FROM products
ORDER BY price ASC, name ASC;

UPDATE users SET role = 'admin'을 WHERE 없이 실행했습니다. 모든 사용자가 admin이 됩니다. DELETE FROM orders를 실수로 치면 주문 데이터 전체가 사라집니다. DML은 즉시 데이터를 바꾸고 트랜잭션 없이는 복구가 어렵습니다. 데이터 변경 쿼리를 쓸 때의 올바른 패턴을 익혀야 이런 사고를 막을 수 있습니다.

확대

INSERT — 데이터 삽입

단건 삽입과 다건 삽입 모두 INSERT INTO 테이블명 (컬럼 목록) VALUES (값 목록) 형식을 사용합니다. 다건 삽입은 VALUES 절에 여러 행을 쉼표로 나열하는 방식으로, 요청 횟수를 줄여 단건 반복 삽입보다 성능상 유리합니다.

INSERT INTO users (name, email, role)
VALUES ('홍길동', 'hong@example.com', 'user');

INSERT INTO products (name, price, category)
VALUES
    ('아이폰 15', 1500000, '전자제품'),
    ('갤럭시 S24', 1200000, '전자제품'),
    ('맥북 프로', 2900000, '컴퓨터');

UPDATE — 데이터 수정

UPDATE에서 WHERE 절은 선택이 아니라 필수입니다. WHERE 없이 실행하면 테이블의 모든 행이 변경됩니다. UPDATE를 실행하기 전에 동일한 WHERE 조건으로 SELECT를 먼저 실행해 대상 행을 확인하는 습관을 들이세요.

SELECT id, name, email FROM users WHERE id = 42;

UPDATE users
SET email = 'newemail@example.com',
    updated_at = NOW()
WHERE id = 42;

UPDATE products
SET price = price * 0.9,
    updated_at = NOW()
WHERE category = '전자제품'
  AND stock > 0;

DELETE vs TRUNCATE vs DROP

세 명령은 모두 데이터를 제거하지만 범위와 안전성이 크게 다릅니다.

DBMS별 주의: BEGIN으로 감싼다고 모든 DBMS에서 TRUNCATE가 되돌아가는 것은 아닙니다. PostgreSQL은 일반적으로 트랜잭션 안에서 TRUNCATE를 롤백할 수 있지만, Oracle은 DDL 자동 커밋으로 앞선 DML까지 확정할 수 있고, MySQL은 스토리지 엔진·설정에 따라 동작이 다릅니다. 아래 TRUNCATE·DROP 예시는 격리된 실습 스키마에서만 실행하고, 사용 중인 DBMS 공식 문서에서 롤백·트리거·FK 동작을 먼저 확인하세요.

-- 아래 명령은 운영 테이블이 아닌 격리된 실습 스키마에서만 실행합니다.
BEGIN;
DELETE FROM cart_items WHERE user_id = 42;
COMMIT;

TRUNCATE TABLE temp_import_data;

DROP TABLE IF EXISTS old_log_table;

실수 방지 트랜잭션 패턴

파괴적인 쿼리를 실행할 때는 BEGIN으로 트랜잭션을 시작하고, 변경 결과를 SELECT로 확인한 뒤 문제가 없으면 COMMIT, 이상하면 ROLLBACK합니다. DELETE 전에 SELECT로 삭제 대상 건수를 미리 확인해두면 실행 후 예상 건수와 비교할 수 있습니다.

BEGIN;

UPDATE orders
SET status = 'cancelled'
WHERE created_at < '2024-01-01' AND status = 'pending';

SELECT COUNT(*), status FROM orders
WHERE created_at < '2024-01-01'
GROUP BY status;

COMMIT;

SELECT COUNT(*) FROM logs WHERE created_at < NOW() - INTERVAL '90 days';

BEGIN;
DELETE FROM logs WHERE created_at < NOW() - INTERVAL '90 days';
COMMIT;

이 모듈이 가르친 안전 습관은 옳습니다 — 파괴적 UPDATE/DELETE는 BEGIN으로 감싸고, SELECT로 확인한 뒤 COMMIT 또는 ROLLBACK 한다. 그런데 이 안전장치에는 초급을 벗어날 때 꼭 알아야 할 비용이 하나 붙어 있습니다.

BEGIN 안에서 UPDATE가 실행되는 순간, DB는 변경한 모든 행에 쓰기 락을 걸고 COMMIT/ROLLBACK이 올 때까지 유지합니다. 즉 "SELECT로 천천히 확인하는" 그 시간 동안, 당신은 그 행들을 잠근 채로 붙들고 있는 것입니다. 같은 행을 바꾸려는 다른 세션은 그동안 대기합니다.

• idle in transaction의 위험: BEGIN과 COMMIT 사이에 딴짓을 하면(창을 바꾸거나 자리를 비우면) 세션이 'idle in transaction' 상태로 남습니다. 락은 계속 걸려 있고, 그 행을 기다리는 다른 요청들이 커넥션을 붙든 채 쌓여 결국 커넥션 풀이 고갈될 수 있습니다.
• VACUUM까지 막는다(PostgreSQL): 오래 열린 트랜잭션은 회수 경계(xmin horizon)를 붙잡아, 그 시간 동안 DB 전체에서 죽은 튜플을 청소하지 못하게 만듭니다. 잠깐의 방치가 테이블 팽창으로 이어집니다.
• 그래서 규율이 함께 온다: 안전 습관의 짝은 "BEGIN→COMMIT 구간을 짧게"입니다. 확인은 빠르게 끝내고 곧바로 커밋하거나 롤백하세요. 커피 마시러 가면서 트랜잭션을 열어 두면 안 됩니다. 대량 변경은 하나의 긴 트랜잭션보다 짧은 배치 여러 개로 나눕니다.

정리하면, "트랜잭션으로 감싸라"는 옳은 조언이지만 "감싼 채 오래 붙들지 마라"가 반드시 따라와야 합니다. 안전장치가 오히려 서비스를 멈추는 락으로 바뀌는 지점이 바로 여기입니다.