Ⅰ MySQL 실행 순서
SQL 쿼리의 실행 순서는 다음과 같이 이해할 수 있습니다:
- 데이터를 가져올 테이블 및 컬럼을 결정
- WHERE 절로 1차 필터링
- GROUP BY 및 HAVING으로 그룹화 후 2차 필터링
- ORDER BY 및 LIMIT 등으로 최종 정렬 및 제한
① 다중 LEFT JOIN 실행 순서
LEFT JOIN이 여러 개 있는 경우, 왼쪽부터 순차적으로 연결됩니다.
-- 메인 테이블: users 연결 테이블: orders, payments
SELECT *
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
LEFT JOIN payments p ON o.id = p.order_id;
-- 실행 순서:
-- 1. users 테이블과 orders 테이블을 u.id = o.user_id로 연결
-- 2. 1번 결과와 payments 테이블을 o.id = p.order_id로 연결
② LEFT JOIN의 ON절 필터 조건
ON절에 필터 조건이 포함되면, 먼저 오른쪽 테이블을 필터링한 후 조인을 수행합니다.
-- 메인 테이블: users 연결 테이블: orders
-- 조건: orders 테이블에서 status = 'active'인 레코드만 조인
SELECT *
FROM users u
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'active';
-- 실행 순서:
-- 1. orders 테이블에서 status = 'active'인 레코드만 먼저 필터링
-- 2. 필터링된 결과를 users 테이블과 LEFT JOIN
ON절 vs WHERE절 필터 차이점
- ON절: 필터링 후 조인 수행 → 오른쪽 테이블만 선별적으로 연결
- WHERE절: 전체 조인 완료 후 결과 집합에서 필터링 → 최종 결과에 영향
-- 예제: 부서(dept)와 직원(employee) 테이블
-- 부서 관점: 각 부서별 직원 현황 파악
SELECT d.name AS dept_name, e.name AS emp_name
FROM dept d
LEFT JOIN employee e ON d.id = e.dept_id;
-- 직원 관점: 모든 직원의 부서 정보 확인
SELECT e.name AS emp_name, d.name AS dept_name
FROM employee e
LEFT JOIN dept d ON e.dept_id = d.id;
-- 두 쿼리의 결과는 동일하나, 비즈니스 관점에서 해석이 다릅니다.
-- 첫 번째 쿼리는 모든 부서의 인력 상황을, 두 번째는 모든 직원의 소속을 중심으로 합니다.
③ LEFT JOIN과 INNER JOIN 선택 기준
- INNER JOIN: 양쪽 테이블에 일치하는 데이터가 반드시 존재할 때 적합 (예: 주문 내역과 결제 정보가 모두 있는 경우)
- LEFT JOIN: 왼쪽 테이블의 모든 행을 유지하면서 오른쪽 테이블과의 매칭 정보를 함께 보고 싶을 때 (예: 모든 직원 목록과 그들의 프로젝트 참여 현황)
Ⅱ 블룸 필터(Bloom Filter) 개념
블룸 필터는 해시 함수를 사용해 데이터를 0 또는 1로 매핑하여 저장하는 공간 효율적인 확률적 자료구조입니다. 큰 데이터를 압축된 비트 배열로 표현하여 빠른 포함 여부 검사를 가능하게 합니다.
핵심 원리
- 데이터를 여러 개의 해시 함수에 통과시켜 여러 비트 위치를 계산
- 해당 비트 위치를 1로 설정하여 저장
- 데이터가 존재하는지 확인할 때, 동일한 해시 함수로 계산된 모든 비트가 1인지 확인
- 하나라도 0이면 "존재하지 않음"을 확실히 알 수 있지만, 모두 1이면 "존재할 가능성"만 알 수 있음(오탐 가능성 존재)
Ⅲ 블룸 필터 실제 활용 사례
시나리오: 10억 사용자 중에서 사용자 이름 중복 여부를 빠르게 확인해야 하는 경우
- MySQL 사용: 10억 레코드를 저장하고 조회 → 저장 공간 과다 + 쿼리 속도 느림
- Redis 기본 저장: 키-값 형태로 저장 → 약 20GB 이상 필요 (각 사용자명을 문자열로 저장)
- Redis + 블룸 필터: 해시 기반 비트 배열로 저장 → 약 1.5GB로 축소 가능 (오차율 허용 시)
블룸 필터는 특히 "데이터가 존재하지 않음"을 빠르게 확인해야 하는 경우(캐시 방어, 중복 방지 등)에 매우 효과적입니다. 다만, 오탐(False Positive) 가능성이 있으므로 정확성이 절대적으로 필요한 경우 추가 검증 단계가 필요합니다.