고객사 환경의 중앙 운영 DB CPU 이상을 슬로우 쿼리와 실행계획으로 추적해, 라이브러리 컴포넌트 테이블의 구조·식별자·데이터 정합성 문제를 근본 원인부터 재설계
CPU 부하가 보이면 서버를 키우고 싶은 유혹이 있지만, 슬로우 쿼리와 실행계획을 따라가 보니 문제는 테이블 구조와 식별자 정책에 있었습니다. 부하가 데이터 정합성과 스키마 문제에서 비롯된 경우였습니다.
라이브러리 컴포넌트 테이블은 제품의 여러 기능이 기대는 중심 테이블이라, 쿼리 튜닝에서 멈추지 않고 collation·스키마·식별자 정책까지 다시 정리했습니다.
고객사 환경에서 중앙 운영 DB의 CPU 이상(부하)이 관측됐습니다. 슬로우 쿼리에서 시작해 실행계획으로 좁혀 보니, 다수 패키지 생태계의 컴포넌트 정보를 담는 라이브러리 컴포넌트 테이블의 구조가 부하·정합성 문제의 근원이었습니다.
varchar) 타입 컬럼에 JSON을 그대로 저장하던 케이스(예: 라이선스 컬럼)가 있어 조회·가공 시 비효율과 데이터 깨짐을 유발슬로우 쿼리에서 원인 쿼리를 찾아 실행계획을 비교했습니다. 뷰를 통한 조인은 collation 차이 때문에 인덱스를 타지 못해 약 130만 건을 스캔했고, 같은 조건으로 테이블을 직접 조인하면 약 6,000건에 그쳤습니다. 이어 varchar에 JSON을 저장하던 케이스를 전체 테이블 대상 전수조사해 영향 범위와 깨진 데이터 비율을 파악하고, 식별자 충돌·대소문자 누락 같은 구조적 문제를 정리한 뒤, 어긋나 있던 collation을 통일하고 스키마·인덱스·식별자 정책을 재설계해 부하와 정합성을 동시에 잡았습니다.
데이터 엔지니어로서 CPU 부하를 만든 쿼리의 실행 계획부터 확인했습니다. 관련 테이블과 인덱스를 전수 조사한 뒤 스키마, 식별자, 인덱스 수정안을 만들고 구현했습니다. 여러 기능이 함께 쓰는 중심 테이블이어서 최종안은 팀장·CTO 리뷰를 거쳐 정했습니다.
collation 통일, 식별자 정책 정비와 스키마·인덱스 재설계가 핵심 변경점. varchar-JSON 컬럼의 타입 정규화는 이 조사에서 발견해 별도 작업으로 진행.