SQL에서 자주 사용하는 집계 함수 중 하나인 COUNT()는 단순히 행의 수를 세는 데에 유용합니다. 하지만 COUNT(*)와 COUNT(컬럼명)은 비슷해 보이지만 실제 의미와 동작 방식에서 중요한 차이를 가지고 있습니다.

COUNT(*)는 모든 행을 센다

COUNT(*)는 해당 테이블에서 NULL을 포함한 모든 행의 개수를 셉니다. 이는 테이블에 존재하는 전체 레코드 수를 파악하고자 할 때 사용됩니다.

예시:

SELECT COUNT(*) FROM employees;

이 쿼리는 employees 테이블의 총 행 수를 반환합니다. 특정 컬럼에 NULL이 있든 없든 관계없이 전체 행 수를 기준으로 계산합니다.

COUNT(컬럼명)는 NULL을 제외한다

반면 COUNT(컬럼명)은 해당 컬럼에서 NULL이 아닌 값의 개수만 셉니다. 즉, 어떤 컬럼의 값이 얼마나 채워져 있는지, 즉 실제 데이터가 있는 레코드 수를 알고 싶을 때 유용합니다.

예시:

SELECT COUNT(department_id) FROM employees;

이 쿼리는 department_id 컬럼의 값이 NULL이 아닌 행의 개수를 반환합니다. 만약 부서가 배정되지 않은 사원이 있다면 그 행은 집계에서 제외됩니다.

실무에서의 활용 팁

• 데이터 완전성 검증 시에는 COUNT(컬럼명)을 사용하여 누락된 값이 있는지 파악합니다.
• 전체 행 수가 필요한 로깅, 페이징 처리 등에서는 COUNT(*)을 사용하는 것이 적절합니다.
• COUNT(DISTINCT 컬럼명)처럼 고유한 값의 개수를 세는 방식과도 구분하여 사용해야 합니다.

결론

COUNT(*)과 COUNT(컬럼명)은 비슷해 보이지만 전혀 다른 결과를 가져올 수 있으므로, 목적에 따라 정확히 구분하여 사용하는 것이 중요합니다. 특히 실무에서 NULL 값이 얼마나 존재하는지를 파악할 때 이 차이를 알고 있으면 보다 정확한 데이터 분석이 가능합니다.

#SQL #COUNT #집계함수 #기초정리 #데이터베이스 #NULL #쿼리

SQL에서 중복된 값을 제거하기 위해 DISTINCT를 사용하고, 데이터를 그룹화하기 위해 GROUP BY를 사용합니다. 하지만 때로는 두 문장이 같은 결과를 반환하기도 하여, 어떤 걸 써야 할지 혼란스러울 수 있습니다. 이 글에서는 두 구문의 차이를 명확하게 정리합니다.

DISTINCT: 단순히 중복된 행을 제거

DISTINCT는 SELECT 절에서 중복된 행을 제거하는 용도로 사용됩니다. 특정 컬럼 또는 여러 컬럼 조합이 중복일 경우, 하나만 남기고 제거합니다.

예시:

SELECT DISTINCT dept_id 
FROM employees;

→ 부서 ID가 중복되는 경우 하나만 표시됩니다.

여러 컬럼을 기준으로도 중복 제거가 가능합니다:

SELECT DISTINCT dept_id, job 
FROM employees;

→ 부서 ID와 직책 조합이 동일한 경우, 하나만 남깁니다.

GROUP BY: 데이터를 그룹으로 묶은 후 집계

GROUP BY는 데이터를 그룹화한 뒤, 집계 함수(SUM, COUNT 등)를 함께 사용할 때 주로 사용됩니다. 단순히 중복 제거가 목적이라면 DISTINCT가 더 적절하지만, 그룹별 통계가 필요하다면 GROUP BY를 사용해야 합니다.

예시:

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

→ 부서별로 몇 명의 직원이 있는지를 보여줍니다.

만약 집계 함수 없이 GROUP BY만 사용한다면 DISTINCT와 유사한 결과가 나오지만, 문장의 의미는 다릅니다.

예시:

SELECT dept_id 
FROM employees 
GROUP BY dept_id;

→ SELECT DISTINCT dept_id FROM employees;와 결과는 같지만, 의미상 그룹화입니다.

정리

실무 팁: 결과만 보고 두 문장을 혼동하면 안 됩니다. 왜 이 구문을 쓰는지, 목적에 따라 구문을 선택하세요.

#SQL #DISTINCT #GROUPBY #중복제거 #집계함수 #기초정리 #실무팁 #데이터분석

SQL에서 조건을 설정할 수 있는 절은 대표적으로 WHERE과 HAVING이 있습니다. 둘 다 데이터를 필터링하는 기능이지만, 사용하는 시점과 용도에는 분명한 차이가 있습니다. 실무에서도 종종 이 둘을 혼용하거나, 쿼리가 잘못 동작하는 원인이 되기도 합니다.

WHERE 절: 집계 전 데이터를 필터링

WHERE 절은 그룹화나 집계가 수행되기 전에 데이터를 필터링합니다. 즉, 원본 테이블에서 조건을 걸고 필요한 행만 남긴 후에 GROUP BY, SUM, AVG 등의 집계 함수가 동작합니다.

예시:

SELECT dept_id, COUNT(*) 
FROM employees
WHERE job = 'MANAGER'
GROUP BY dept_id;

→ 여기서 WHERE은 "직책이 MANAGER인 직원"만 대상으로 그룹화합니다.

HAVING 절: 집계 이후 그룹 필터링

HAVING 절은 GROUP BY 이후 집계된 결과에 조건을 거는 데 사용합니다. WHERE과 달리 집계 함수(COUNT, SUM, 등)를 사용할 수 있습니다.

예시:

SELECT dept_id, COUNT(*) AS cnt
FROM employees
GROUP BY dept_id
HAVING COUNT(*) >= 5;

→ 모든 부서를 그룹화한 후, 직원 수가 5명 이상인 부서만 결과로 출력됩니다.

둘 다 쓰는 경우

두 절을 함께 쓰는 것도 가능합니다. 이때는 WHERE이 먼저, HAVING이 나중에 적용됩니다.

SELECT dept_id, COUNT(*) 
FROM employees
WHERE job = 'MANAGER'
GROUP BY dept_id
HAVING COUNT(*) >= 2;

→ MANAGER만 대상으로 부서별 그룹을 만들고, 그중에서 2명 이상인 부서만 필터링합니다.

실무 팁으로 기억하면 좋습니다:

• WHERE은 개별 행을 필터링
• HAVING은 집계 결과를 필터링

이 원칙만 기억하면 두 조건절을 헷갈릴 일이 줄어듭니다.

#SQL #WHERE절 #HAVING절 #조건절 #GROUPBY #집계함수 #기초정리 #실무팁

SQL에서 LEFT JOIN은 왼쪽 테이블의 모든 데이터를 기준으로 오른쪽 테이블과 연결해주는 기능입니다. 하지만 실무에서는 종종 LEFT JOIN을 썼는데도 결과가 예상보다 적게 나오는 일이 발생합니다. 이 글에서는 그런 상황에서 확인해야 할 3가지 핵심 원인을 소개합니다.

1. WHERE 절 조건이 JOIN 결과를 제한한다

아래 쿼리를 살펴봅시다:

SELECT *
FROM employees e
LEFT JOIN departments d ON e.dept_id = d.id
WHERE d.location = 'SEOUL';

의도는 모든 직원 정보를 보고 싶은 것인데, 이 쿼리는 d.location이 NULL인 직원(=부서가 없는 직원)은 제외됩니다. 이는 WHERE 절이 조인 이후에 적용되기 때문입니다.

→ 해결책은 조건을 JOIN 안에 넣는 것입니다:

SELECT *
FROM employees e
LEFT JOIN departments d ON e.dept_id = d.id AND d.location = 'SEOUL';

이렇게 하면 부서가 없는 직원도 빠지지 않습니다.

2. JOIN 조건이 누락되거나 잘못되었다

SELECT *
FROM employees e
LEFT JOIN departments d ON e.name = d.name;

이런 식으로 정확한 조인 조건 없이 컬럼 이름만 같은 걸 기준으로 조인하면 원하지 않는 결과가 나옵니다. 항상 기본키-외래키 관계 또는 고유한 값을 기준으로 조인해야 합니다.

3. 중첩 JOIN과 서브쿼리에서 발생하는 필터링

복잡한 쿼리일수록 LEFT JOIN이 서브쿼리 내부에 있거나 INNER JOIN과 함께 쓰이면서 무의식적으로 결과가 줄어들 수 있습니다. 쿼리 구조를 항상 시각화하면서 데이터 흐름을 따져보는 습관이 필요합니다.

LEFT JOIN은 단순한 듯 보여도 실무에서는 자주 함정에 빠지는 구간입니다. 특히 WHERE 절의 위치나 조인 조건에 따라 결과가 확 달라질 수 있으니 항상 주의 깊게 쿼리를 작성해야 합니다.

#SQL #JOIN #LEFTJOIN #외부조인 #누락 #쿼리디버깅 #기초정리 #실무팁

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별표 #쿼리작성 #성능 #실무팁 #데이터베이스 #기초정리

SQL을 처음 접할 때 가장 혼동하기 쉬운 개념 중 하나가 바로 NULL입니다. 많은 분들이 NULL을 숫자 0이나 빈 문자열로 오해하지만, 실제로는 값이 존재하지 않음을 의미합니다.

NULL은 어떤 의미인가요?

• NULL은 값이 존재하지 않음을 나타냅니다.
• 숫자 0(0)은 실제 값이고, NULL은 값 자체가 없음입니다.
• 빈 문자열('')도 NULL과 다릅니다. 빈 문자열은 값이지만, 비어있는 값일 뿐입니다.

NULL을 비교할 때 주의할 점

일반적인 비교 연산자(=, !=)로는 NULL 값을 정확히 비교할 수 없습니다. 예를 들어 다음 쿼리는 아무 결과도 반환하지 않습니다.

SELECT * FROM employees WHERE commission_pct = NULL;

이유는 NULL = NULL은 참이 아니라 알 수 없음(UNKNOWN)이 되기 때문입니다. NULL 비교는 반드시 IS NULL 또는 IS NOT NULL을 사용해야 합니다.

SELECT * FROM employees WHERE commission_pct IS NULL;

집계 함수와 NULL

• COUNT(*)는 모든 행을 세지만
  COUNT(column)은 해당 컬럼이 NULL이 아닌 값만 셉니다.
• SUM, AVG, MAX, MIN 같은 집계 함수도 NULL은 무시하고 계산합니다.

실무에서 자주 발생하는 실수

• 조건절에 = NULL 사용 → 항상 결과가 없음
• 조인 시 NULL값이 있는 컬럼 누락 → 원하는 결과 누락
• 정렬(SORT) 결과가 예상과 다름 → NULLS FIRST 또는 NULLS LAST 명시 필요

SQL에서 NULL은 단순한 "빈 값"이 아닌, 존재하지 않는 상태로 간주됩니다. 쿼리 작성 시 NULL의 의미를 정확히 이해하고 조건절이나 집계 함수에서 적절히 처리하는 것이 매우 중요합니다.

#SQL #NULL #값비교 #ISNULL #쿼리실수 #기초정리 #데이터베이스