1. 인덱스도 함께 갱신해야 하기 때문이다.
테이블에 데이터를 삽입하거나 수정하면, 해당 행이 포함된 모든 인덱스도 함께 업데이트되어야 한다.
삭제할 때도 마찬가지로, 해당 키를 인덱스에서 제거하는 작업이 필요하다.
예시
email 컬럼에 인덱스가 있고 이 값을 수정하면, 인덱스 트리 구조에서 기존 값을 제거하고 새 값을 다시 삽입해야 한다.
2. B+Tree 인덱스의 유지 비용
MySQL에서 인덱스는 대부분 B+Tree 구조를 기반으로 한다.
B+Tree는 균형 트리 구조를 유지해야 하므로, 새로운 데이터를 삽입하거나 기존 데이터를 삭제할 때 트리의 균형을 맞추는 작업(rebalancing)이 발생할 수 있다.
이 과정에서 노드 분할(split)이나 병합(merge)이 일어나며, 이는 결국 디스크 I/O를 증가시키고 쓰기 성능을 저하시킨다.
예시
- 새로운 값이 리프 노드의 공간을 초과하면 노드를 분할(split)해야 함
- 삭제 후 노드의 값이 너무 적어지면 다른 노드와 병합(merge)이 필요함
이러한 작업은 모두 디스크에 접근해야 하므로, 쓰기 작업이 많을수록 인덱스 유지 비용이 높아진다.
즉, 읽기 성능을 높이기 위해 인덱스를 많이 만들면, 반대로 쓰기 성능은 저하될 수 있으므로 적절한 균형이 필요하다.
3. 다중 인덱스일수록 부하가 누적된다.
한 테이블에 인덱스가 여러 개 존재할 경우, 하나의 레코드 CUD 작업 시 모든 인덱스 구조를 각각 갱신해야 하므로, 작업 시간이 선형적으로 늘어난다.
특히 OLTP 시스템처럼 쓰기 작업이 빈번한 환경에서는 성능 저하가 뚜렷하게 나타난다.
- OLTP(Online Transaction Processing) - 온라인 트랜잭션 처리
짧고 잦은 데이터 처리 요청을 실시간으로 처리하는 시스템
4. Undo/Redo 로그 증가
인덱스 변경도 트랜잭션의 일환으로 처리되므로, 관련 로그가 DBMS 내부의 Undo/Redo 영역에 기록된다.
이로 인해 로그 영역 부담 증가 → 디스크 사용량, 복구 시간, 체크포인트 간격 등에 부정적 영향을 줄 수 있다.
