주문 테이블에 기본키와 고객 ID 인덱스가 있는데 고객별 주문 조회 비용이 예상보다 큽니다. DB의 실제 행 배치와 보조 인덱스가 행을 찾는 방식을 어떻게 확인하나요?

기본키는 행을 논리적으로 식별하는 제약이고, 클러스터링은 행을 어떤 순서·구조로 저장할지에 관한 물리적 선택입니다. 따라서 기본키가 있다고 고객별 주문 조회가 자동으로 빠르지는 않습니다. 먼저 테이블이 힙인지, 기본키 인덱스가 클러스터드 구조인지, 보조 인덱스의 리프가 물리 주소를 담는지 클러스터링 키를 담는지 엔진의 실제 계약을 확인하겠습니다.

보조 인덱스 뒤의 추가 접근을 계산합니다

고객 ID 보조 인덱스가 있으면 고객 ID의 구간을 찾는 것까지는 빠를 수 있습니다. 그러나 선택한 주문 ID나 클러스터링 키만 얻고 total_amount, created_at 같은 반환 컬럼을 원본 구조에서 다시 읽어야 하면 행마다 lookup이 발생합니다. 고객별 주문이 적을 때는 괜찮지만 한 고객이 수십만 건을 갖거나 결과 컬럼이 넓으면 많은 임의 페이지 접근이 생깁니다. 인덱스에 필요한 반환 컬럼을 포함한 covering 형태는 이 추가 접근을 줄일 수 있지만 인덱스 페이지와 쓰기 유지 비용을 늘립니다.

SQL Server의 클러스터드 인덱스와 힙은 보조 인덱스가 행을 찾는 방식이 다르고, PostgreSQL의 heap과 MVCC 버전 관리도 단순한 물리 주소 조회만으로 끝나지 않을 수 있습니다. InnoDB처럼 기본키가 행 저장의 기준이 되는 엔진에서는 보조 인덱스에 기본키가 반복될 수 있어 기본키 폭이 모든 보조 인덱스 크기에 영향을 줍니다. 이런 차이를 모른 채 ‘클러스터드면 보조 인덱스가 곧 행이다’라고 말하면 비용을 잘못 추정하게 됩니다.

클러스터링 키는 대표 작업과 쓰기 패턴으로 정합니다

순차 증가 키는 새 행을 끝쪽에 넣어 임의 페이지 분할을 줄일 수 있지만, 고동시성 삽입이 마지막 페이지에 몰려 경합을 만들 수 있습니다. 임의 키는 삽입 위치를 분산할 수 있어도 페이지 분할·조각화·캐시 효율 저하가 생길 수 있습니다. 시간과 비슷한 키를 선택해도 시간 범위 조회가 자동으로 해결되는 것은 아니므로 별도 인덱스가 필요한지 확인합니다. 넓은 문자열 키는 보조 인덱스에 반복될 때 저장·읽기 비용을 크게 만들 수 있습니다.

진단은 고객별 적은 결과와 큰 결과를 나눠 실제 실행 계획, 논리·물리 읽기, lookup 횟수, 반환 행 수를 비교하는 순서로 하겠습니다. 클러스터링 변경은 읽기만 빠르게 만드는 실험이 아니라 삽입·갱신·백업·재구성 비용까지 바꾸므로 대표 쓰기 부하에서 p99를 확인합니다. SQL Server라면 힙/클러스터드 실행 계획과 key lookup을, 다른 DBMS라면 해당 엔진의 heap visibility·클러스터링 구현과 인덱스 통계를 별도로 확인하겠습니다. 최종 기준은 용어가 아니라 자주 읽는 순서와 유지 비용의 균형입니다.

특히 ‘고객별 비용’은 평균 고객만 보면 안 됩니다. 특정 고객에 주문이 몰리는 데이터 편중은 보조 인덱스의 seek를 lookup 폭증으로 바꾸고, covering 인덱스는 이 사례를 완화하는 대신 모든 주문 변경의 인덱스 갱신량을 늘립니다. 실행 계획에서 estimated/actual row, key lookup, page read를 고객 규모별로 비교하고, 온라인 재구성이나 인덱스 rebuild가 운영 잠금·로그에 미치는 영향도 변경 절차에 포함하겠습니다.