🤔 데이터베이스, 더 똑똑하게 만들 수는 없을까?
점점 길어지는 SQL문을 보며 문득 이런 생각이 들었다.
‘파이썬에서 처럼 편리하게 함수를 정의할 순 없을까? 데이터가 산더미처럼 쌓여도 성능을 유지할 방법은 없을까?’
오늘은 그 해답을 찾는 시간이었다.
스토어드 프로시저로 반복적인 SQL을 함수처럼 만들고,
트리거로 특정 이벤트에 자동으로 반응하게 하며,
파티션으로 대용량 테이블을 효율적으로 관리하는 법을 배웠다.
데이터베이스를 단순한 저장소가 아닌, 살아 움직이는 시스템으로 만드는 고급 기술들이었다.
⚙️ 스토어드 프로시저: 나만의 SQL 함수 만들기
복잡한 쿼리 묶음을 매번 실행하는 것은 번거로운 일이었다.
스토어드 프로시저는 이 SQL 꾸러미에 이름을 붙여두고, CALL 한 번으로 실행할 수 있게 해주는 기능이었다.
| 장점 | |
|---|---|
| 성능 향상 | 서버 안에서 모든 게 처리되니, 네트워크를 타는 시간이 줄어든다는 점이 매력적이었다. |
| 모듈화 | 자주 쓰는 기능을 프로시저로 만들어두면, 코드가 깔끔해지고 재사용하기도 좋을 것 같다. |
| 개발 분업 | DB 전문가는 프로시저 API를 만들고, 나는 그걸 가져다 쓰기만 하면 되니, 협업이 훨씬 수월해질 것 같다. |
-- 특정 연도 이전에 입사한 직원 수를 찾는 프로시저를 만들며 그 편리함을 체감했다.
DELIMITER //
CREATE PROCEDURE employees_hireyear(OUT employee_count INT)
BEGIN
SELECT COUNT(*) INTO employee_count
FROM fisa.emp WHERE YEAR(hiredate) < 1982;
END //
DELIMITER ;
CALL employees_hireyear(@count);
SELECT @count;
앞으로 반복되는 작업은 꼭 프로시저로 만들어 관리할 수 있게 되었다.
🔫 트리거: 데이터베이스의 자동화 센서
트리거는 데이터에 변화가 생길 때(INSERT, UPDATE, DELETE) 약속된 행동을 자동으로 실행하는 기능이었다.
마치 문이 열리면 자동으로 불이 켜지는 센서 같았다.
예를 들어, 주문이 취소되면(DELETE) 해당 데이터를 백업 테이블에 자동으로 옮기는 식이다.
이런 자동화 로직 덕분에 데이터의 일관성을 유지하고, 중요한 변경 이력을 놓치지 않을 수 있겠다는 확신이 들었다.
하지만, 트리거는 눈에 보이지 않게 동작하기 때문에
너무 복잡하게 만들면 나중에 디버깅하기 어려울 수 있겠다는 생각도 들었다.
꼭 필요하고 명확한 작업에만 신중하게 사용해야겠다.
🗂️ 파티션: 거대한 책상을 서랍으로 나누는 지혜
수억 건의 데이터가 담긴 테이블을 상상해보자. 원하는 데이터를 찾으려면 책상 전체를 뒤지는 것과 같을 것이다.
파티션은 이 거대한 책상에 서랍을 만들어주는 기술이었다.
입사 연도별로 서랍을 나누고(RANGE 파티션), 1982년 입사자를 찾으라고 하면
DB는 1982년 서랍만 열어보면 되니, 속도는 당연히 빨라진다.
이것을 파티션 프루닝(Partition Pruning) 이라고 부른다는 것도 배웠다.
-- 입사 연도별로 파티션을 나누니, 특정 연도 조회 시 성능이 향상되는 것을 EXPLAIN으로 확인했다.
EXPLAIN SELECT ename FROM emp_p WHERE YEAR(hiredate) = 1982;
대용량 데이터를 다룰 때 파티션은 선택이 아닌 필수임을 깨달았다.
어떤 기준으로 파티션을 나눌지(파티션 키)를 잘 설계하는 것이 핵심이라는 생각이 들었다.
✨ 오늘의 회고
오늘은 데이터베이스의 자동화와 성능 최적화라는 두 마리 토끼를 잡는 법을 배웠다.
- 스토어드 프로시저로 반복을 줄이고,
- 트리거로 실수를 방지하며,
- 파티션으로 성능을 확보하는 것.
이 세 가지를 잘 수행하고, 데이터베이스 시스템 전체를 설계하는 개발자로 성장하고 싶다는 목표가 더욱 뚜렷해졌다. 🚀