[CS]2026.01.31 면접준비

◆ long의 필요이유

int는 32비트로 -21억~+21억 까지의 숫자가 표현이 가능함. 이전에 기억나는 큰 이슈로 유튜브에서 싸이의 강남스타일이 21억뷰가 넘어가면서 오류가 발생함. 실제로 int타입을 사용해서 마이너스로 표기되던 오버플로우가있던 사건으로 기억한다. 그래서 유튜브는 타입을 long으로 변경하여 쓰고 있다고 들음.long타입은 922경의 숫자가 표현될 수 있기에 앞으로의 오류는 없을거라고 본 기억이 있다. 이런것처럼 오버플로우나 치명적인 오류가 발생할 수 있기때문에 타입의 정확한 기획이 필요하다고 느껴진다.

 

 

◆ PK(기본키)를 생성하면 왜 검색이 빨라지나요?

클러스터드 인덱스는 실제 데이터가 정렬되어 저장되는 방식이고, 넌클러스터드는 데이터는 따로 있고 주소만 있는 색인 방식(Heap)이다. 즉 기본키는 클러스터드 방식인데 검색이 빨라지는 핵심 이유는 데이터가 물리적으로 정렬되기 때문이다.

 

데이터가 순서대로 정렬되어 있으므로, 데이터가 100만 건이 있어도 단 몇 번의 비교만으로 원하는 값을 찾을 수 있다. 데이터가 모여 있기 때문에 범위 검색(Between, <, >)에 매우 강력한 장점이 있지만, 데이터의 삽입(Insert)이나 수정(Update) 시, 정렬 순서를 유지하기 위해 데이터를 밀어내거나 페이지를 분할하는 작업이 필요해 부하가 발생할 수 있다. 부하가 발생하는 경우는 DB의 저장 되는 방식 때문인데 저장되는 방식이 한곳에서 이루어지는게 아니라 페이지별로 기록되기 때문이다. 예를 들어 1페이지에 내용이 1,5,10의 인덱스만 있고 2페이지에는 11,13,17이 있다고 가정해보자. 그럴경우 무언가의 필요성에 의해 2라는 인덱스가 추가가 되어야 할경우는 10의 인덱스가 2페이지로 들어가야하고 17은 3페이지가 생겨야 하는 상황이 발생한다. 이럴 경우의 상태 때문에 오히려 데이터의 삽입과 수정시에는 부하가 발생할 수 있는 것이다.

 

넌클러스터드 인덱스 방식으로 검색을 하면 오래걸리는 이유가 예를 들어 홍길동을 찾고 싶은데 우리가 살고 있는 집주소만 알려주고 그 안에 4명이 살고 있으면 그 4명중에 홍길동이란 사람을 또 찾아야해서 그렇다. 즉 데이터를 2번 조회해야해서 오래걸리는 단점이 있다면, 클러스터드 인덱스랑 반대로 힙 방식으로 정리되기 때문에 빈공간에 데이터를 삽입하면 끝이어서 데이터 삽입이 훨씬 용이하다.

 

커버링 인덱스 개념도 있는데 내용이 너무 길어지므로 더 공부하고 싶으면 찾아보면 될듯하다.

뭐 간단하게 설명하면 

 

SELECT   원하는_컬럼 
FROM     테이블_이름 
WHERE    조회할_컬럼 = '데이터_값';

이렇게 검색하는 방식으로 생각하면 좋을 듯하다.