월 매출 쿼리에 쿠폰판매 합산

월 매출 쿼리에 쿠폰판매 합산 + 주석 정비

리팩토링 작업을 완료했음.

리팩토링 이유

쿼리가 복잡해지면서 실행 계획을 예측하기 어려워졌음. 가독성과 성능을 동시에 개선했음.

변경 전/후

-- 수정 후: 명확한 컬럼 구조
SELECT
  DATE_FORMAT(t.created_at, '%Y-%m') as month,
  SUM(CASE WHEN t.type = 'SALES' THEN t.amount ELSE 0 END) as total_sales,
  SUM(CASE WHEN t.type = 'FEE' THEN t.amount ELSE 0 END) as total_fee,
  SUM(CASE WHEN t.type = 'SALES' THEN t.amount ELSE 0 END)
    - SUM(CASE WHEN t.type = 'FEE' THEN t.amount ELSE 0 END) as net_profit
FROM 내부테이블 t
GROUP BY month
ORDER BY month DESC;

변경 범위

SQL 매퍼 1개

기대 효과

코드 가독성이 높아지고 수정 비용이 낮아졌음. 동일 기능을 더 적은 코드로 표현하게 됐음.

회귀 검증

리팩토링은 외부 동작을 바꾸지 않아야 함. 입력/출력이 동일한지 주요 케이스를 기준으로 확인했음. 내부 구조만 변경했고, 배포 후 이상 없이 동작했음.

DB 설계 고려사항

이번 작업에서 DB 쿼리를 작성하면서 몇 가지를 점검했음.

인덱스 활용: WHERE 조건에 사용하는 컬럼에 인덱스가 있는지 확인했음. 특히 status, created_at 같은 자주 필터링하는 컬럼은 복합 인덱스를 고려했음.

-- 인덱스 설계 예시
CREATE INDEX idx_status_created ON 내부테이블 (status, created_at DESC);
-- status 필터링 후 최신순 정렬이 많을 때 유효

소프트 삭제: 데이터를 물리적으로 삭제하지 않고 deleted_at 컬럼으로 논리 삭제하는 패턴을 유지했음. 이력 추적이 필요한 데이터는 지우면 안 됨.

페이징: 대량 데이터 조회 시 LIMIT/OFFSET 방식이 현재 규모에서는 충분했음. 데이터가 많아지면 커서 기반 페이징으로 전환을 고려해야 함.

월 매출 쿼리에 쿠폰판매 합산