[question] 테이블 연관시 인덱스 사용 전략 어떻게 가져가고 계신가요?

[binchoo]

질문

13장 p.359 - 외래키 제약 조건에 인덱스를 걸지 않아서 시스템이 몇 시간 동안 중단되는 경우는 흔하다.

1. 외래키 인덱스 누락 사례를 말씀 주셨는데, 좀 의문이 들었습니다. 외래키 정의시 인덱스로도 만들어 지는 줄로 알았거든요. InnoDB에서는 맞는 얘기고, MSSQL은 꼭 그렇지 않다는 답변이 확인되어서 공유 드립니다.

   ▶️ MSSQL: 외래키는 자동으로 인덱스를 만드나요?

2. 외래키 및 인덱스를 사용해야 하는가에 대해서 다음과 같은 논의를 들어봤는데요.

   • 외래키 제약은 그 변경을 전파해야 해서 성능상 부담스러울 수 있음: NULL 처리, CASCADE 처리 또는 아예 불변 처리 필요
   • 따라서 무결성을 포기하고, 성능과 확장을 위해 외래키 제약 빼고 인덱스만 적용

제가 DB는 Grafana로 소규모 테이블을 긁는 때만 써서,, 저정도로 확장성을 고려하진 않습니다. 여러분 규모에서 특이한 결정 사항이 있으셨다면 한 번 얘기해 볼 수 있다면 좋겠습니다.

연관 챕터

36

---

@caffeine-library/readers-release-everything

[emiling]

외래키 및 인덱스를 사용해야 하는가에 대해서 다음과 같은 논의를 들어봤는데요

• 외래키 제약은 그 변경을 전파해야 해서 성능상 부담스러울 수 있음: NULL 처리, CASCADE 처리 또는 아예 불변 처리 필요
• 따라서 무결성을 포기하고, 성능과 확장을 위해 외래키 제약 빼고 인덱스만 적용

저희 회사에서도 별도의 FK를 걸진 않고 있긴 하고, 저도 FK 거는 것에 대하여 아직은 의문이긴 합니다. 아직까지 FK를 잘 걸어서 시스템을 유연하게 구성하는 케이스를 못봐서 그런 것일수도 있습니다. 이러한 생각에 대한 제 이유를 물어보면 아래와 같이 대답하긴 합니다.

• 비지니스 요구사항이 빠르게 변경됨에 따라 테이블 구조까지 변경이 전파되는 경우가 많음
  • 이런 경우 제약을 엄격하게 가져가는 것보다 데이터 일관성을 어느정도 포기하고 느슨하게 가져감
  • 테이블 구조 변경 등으로 인한 DB 마이그레이션 시 제약조건 (레거시 데이터는 이러한 일관성이 안맞아 마이그 때 힘든 경우도 꽤 있음)
• 경계 관리
  • 영역간의 데이터 결합도 증가
• 성능
  • 기본키값이 변경되거나 삭제될 때 CASCADE 되어 함께 변경되는 비용