SQL에서 조건에 따라 다른 값을 출력해야 할 때 CASE WHEN 구문을 사용합니다. 이는 프로그래밍 언어에서의 if-else처럼 조건 분기를 처리할 수 있도록 도와주며, 특히 SELECT 문 안에서 동적으로 컬럼 값을 제어할 때 자주 사용됩니다.

CASE WHEN의 기본 구조

CASE 구문은 다음과 같은 형식으로 작성합니다.

SELECT 컬럼명,
       CASE
           WHEN 조건1 THEN 결과1
           WHEN 조건2 THEN 결과2
           ELSE 기본값
       END AS 별칭
FROM 테이블명;

조건이 참인 첫 번째 WHEN 절이 실행되고, 해당 조건이 모두 거짓인 경우 ELSE 절의 값이 반환됩니다.

실무 예시: 고객 등급 분류

예를 들어, 고객의 구매 금액을 기준으로 등급을 나누는 쿼리는 다음과 같습니다.

SELECT 고객명,
       구매금액,
       CASE
           WHEN 구매금액 >= 100000 THEN 'VIP'
           WHEN 구매금액 >= 50000 THEN '우수'
           ELSE '일반'
       END AS 고객등급
FROM 고객테이블;

이 쿼리를 사용하면 금액에 따라 각 고객이 어떤 등급인지 자동으로 분류할 수 있습니다.

GROUP BY, ORDER BY와 함께 사용

CASE 문은 GROUP BY나 ORDER BY와 함께 쓰일 때도 강력한 유연성을 발휘합니다. 예를 들어, 지역별로 '수도권'과 '비수도권'을 나눠 집계하고 싶을 때는 다음과 같이 활용합니다.

SELECT
    CASE
        WHEN 지역 IN ('서울', '경기', '인천') THEN '수도권'
        ELSE '비수도권'
    END AS 권역,
    COUNT(*) AS 고객수
FROM 고객테이블
GROUP BY
    CASE
        WHEN 지역 IN ('서울', '경기', '인천') THEN '수도권'
        ELSE '비수도권'
    END;

주의할 점

• CASE 구문은 WHERE 절에서 직접 사용할 수 없습니다. 조건 분기가 필요한 경우엔 서브쿼리나 CTE(Common Table Expression)로 처리하는 것이 일반적입니다.
• 조건 순서가 중요합니다. 먼저 작성된 WHEN 조건부터 평가되므로, 조건이 중첩될 수 있는 경우에는 우선순위를 고려해야 합니다.

마무리

CASE WHEN 구문은 SQL에서 데이터를 조건에 따라 분기해 보여줄 때 매우 유용한 도구입니다. 특히 복잡한 조건을 단일 컬럼 안에서 처리할 수 있어 가독성과 유지보수 측면에서도 장점이 많습니다. 실무에서도 흔히 사용되는 만큼, 다양한 상황에 적용해보며 익숙해지는 것이 중요합니다.

#SQL #CASE문 #조건분기 #SQL기초 #WHENTHEN #쿼리작성팁 #SELECT문 #데이터분석

SQL을 처음 배울 때 가장 먼저 접하게 되는 문장이 SELECT * FROM 테이블명입니다. 모든 컬럼을 조회할 수 있어 편리하지만, 실무에서는 대부분의 경우 SELECT * 사용을 지양합니다. 왜 그럴까요?

1. 성능 저하

SELECT *는 테이블의 모든 컬럼을 조회하므로, 필요한 컬럼만 선택한 경우보다 훨씬 많은 데이터를 읽게 됩니다. 특히 테이블에 수십 개의 컬럼이 있을 경우, 불필요한 IO 작업이 증가하고 네트워크 부하도 커지게 됩니다.

2. 유지보수의 어려움

테이블 구조가 변경되면 SELECT *의 결과도 바뀔 수 있습니다. 예를 들어 새 컬럼이 추가되었을 때, 의도치 않게 쿼리 결과가 달라져 에러가 발생하거나 보고서 양식이 깨지는 등의 문제가 생길 수 있습니다.

3. 가독성과 명확성 부족

어떤 컬럼이 사용되는지 코드만 보고는 알 수 없습니다. 반면 컬럼을 명시하면 해당 쿼리가 어떤 데이터를 다루는지 명확히 알 수 있어 유지보수와 협업에 유리합니다.

4. 인덱스 무효화 가능성

인덱스를 활용하는 쿼리의 경우, SELECT *로 인해 인덱스만으로는 데이터를 충족할 수 없어 테이블 전체를 읽는 Full Table Scan이 발생할 수 있습니다.

정리하자면

가능한 한 필요한 컬럼만 명시하는 습관을 들이는 것이 좋습니다. 예를 들어:

SELECT emp_id, emp_name, salary
FROM employees;

이렇게 쓰면 성능도 좋고, 명확성도 올라가며 유지보수도 쉬워집니다. SELECT *는 학습 단계에선 도움이 되지만, 실무에선 피해야 할 문장입니다.

#SQL #SELECT문 #SELECT별표 #쿼리작성 #성능 #실무팁 #데이터베이스 #기초정리

GROUP BY와 ORDER BY의 차이는 뭘까? 비슷해 보이지만 전혀 다른 역할

SQL을 처음 배우면 자주 혼동되는 개념 중 하나가 GROUP BY와 ORDER BY입니다. 둘 다 SELECT문에서 자주 사용되며 컬럼 이름을 기준으로 뭔가를 "묶거나 정렬"하는 것 같지만, 실제로는 그 목적과 동작 방식이 완전히 다릅니다. 이번 글에서는 이 두 구문의 차이를 예제와 함께 명확히 정리해 보겠습니다.

1. GROUP BY – 같은 값을 하나의 그룹으로 묶기

GROUP BY는 집계 함수(COUNT, SUM, AVG 등)와 함께 사용되어 같은 값을 가진 행들을 하나의 그룹으로 묶습니다. 예를 들어, 부서별 사원 수를 구하고자 할 때 사용됩니다.

SELECT department_id, COUNT(*) 
FROM employees 
GROUP BY department_id;

위 쿼리는 department_id가 같은 행들을 묶어 각 부서에 몇 명이 있는지 알려줍니다.

✅ 핵심: GROUP BY는 묶기 (집계 대상 그룹 생성)

2. ORDER BY – 결과를 원하는 순서로 정렬

ORDER BY는 쿼리 결과의 행 순서를 정렬합니다. 오름차순(ASC) 또는 내림차순(DESC)으로 정렬할 수 있으며, 집계와는 아무런 관련이 없습니다.

SELECT employee_id, salary 
FROM employees 
ORDER BY salary DESC;

위 쿼리는 월급이 높은 순으로 직원을 나열하며, 어떤 그룹화도 하지 않습니다.

✅ 핵심: ORDER BY는 정렬 (출력 순서 제어)

3. 둘을 함께 사용하는 예

GROUP BY로 먼저 그룹을 만든 후, 그 결과를 ORDER BY로 정렬할 수도 있습니다.

SELECT department_id, AVG(salary) AS avg_salary 
FROM employees 
GROUP BY department_id 
ORDER BY avg_salary DESC;

이 쿼리는 부서별 평균 급여를 계산한 뒤, 평균이 높은 부서부터 나열합니다.

✅ 마무리

• GROUP BY: 집계를 위해 데이터를 묶는 역할
• ORDER BY: 결과를 정렬하는 역할

두 구문은 비슷해 보이지만 완전히 다른 용도입니다. 실무에서는 이 둘을 함께 사용하는 경우도 많기 때문에 그 차이를 정확히 이해하는 것이 중요합니다.

#SQL #GROUPBY #ORDERBY #정렬 #집계 #SELECT문 #기초문법 #실무팁

DISTINCT는 정말 중복만 제거할까? 사용 시 주의해야 할 3가지 포인트

SQL을 처음 배우거나 실무에서 데이터를 정제할 때 자주 등장하는 키워드 중 하나가 DISTINCT입니다. 보통은 "중복 제거" 용도로만 알고 있지만, 생각보다 주의할 점이 많아 잘못 쓰면 원하는 결과를 얻지 못하거나 오히려 성능이 떨어질 수 있습니다. 이번 글에서는 DISTINCT 사용 시 꼭 알아야 할 3가지 핵심 포인트를 정리해보겠습니다.

1. DISTINCT는 SELECT 절 전체 컬럼 조합의 중복을 제거합니다

많은 초보자들이 실수하는 부분입니다. DISTINCT는 단일 컬럼 기준이 아니라, SELECT 절에 명시된 전체 컬럼 조합이 동일한 경우에만 중복으로 판단합니다.

SELECT DISTINCT name, department FROM employees;

위 쿼리는 이름이 같더라도 부서가 다르면 중복으로 간주하지 않습니다. 따라서 원하는 결과가 아니라면 컬럼 선택을 신중하게 해야 합니다.

2. 정렬 순서를 바꾸면 결과는 같지만 처리 방식은 달라질 수 있습니다

DISTINCT를 사용할 때 정렬 순서는 결과값에 영향을 주진 않지만, 내부적으로 처리되는 방식은 바뀔 수 있습니다. 특히 ORDER BY를 추가하면 SQL 엔진은 정렬 연산을 추가로 수행하기 때문에 성능 차이가 날 수 있습니다.

SELECT DISTINCT department FROM employees ORDER BY department;

이처럼 DISTINCT와 ORDER BY를 함께 사용할 때는 인덱스 활용 여부나 정렬 비용을 고려해야 합니다.

3. DISTINCT는 성능상 이슈를 유발할 수 있습니다

중복 제거는 단순해 보여도 실제로는 많은 비용이 발생할 수 있습니다. 내부적으로는 정렬(SORT) 또는 해시(HASH) 기반의 비교 연산이 일어나며, 데이터 양이 많아질수록 작업량도 크게 증가합니다.

대량의 데이터를 다룰 때는 DISTINCT보다 GROUP BY를 고려하거나, 아예 애초에 데이터가 중복되지 않도록 설계하는 것이 더 효율적일 수 있습니다.

✅ 마무리

DISTINCT는 단순한 기능이지만, 그 동작 원리를 정확히 알고 사용하지 않으면 엉뚱한 결과를 초래하거나 불필요한 성능 저하를 일으킬 수 있습니다. 실무에서는 반드시 컬럼 조합과 데이터 특성을 이해한 뒤에 신중히 사용하는 습관이 필요합니다.

#SQL #DISTINCT #중복제거 #기초문법 #SELECT문 #실무팁 #데이터정제