클러스터 인덱스로 만들

2개 컬럼에 대해 단편화 문제가 없다면

생각하시는 것처럼 해도 될 것 같습니다.

join도 없고 where도 없는 등이라면 말씀대로 클러스터드 인덱스가 최선일 수 있겠지만 identity를 만드셔야 되는 이유가 join이나 where 등에 사용하시려고 하시는 것은 아닌지...

MS-SQL은 pk를 기준으로 clustered index를 생성하지 않아도 되므로(MySQL의 InnoDB는 허용하지 않지만요) 어지간하면 pk는 만드시는 편이 좋겠습니다.

두분 답변감사드립니다 ㅎㅎ
제가 DB를 전문적으로 다루지를 않아서 
밑에는 테이블 구조 이해를 돕고자 작성하였습니다.
 

Table(
 - ID -> IDENTITY
 - Value1
 - Value2 )
Clustered Index (Value1, Value2)
Non Clustered Index (ID)

1. SELECT할때 WHERE절에서 ID를 많이 사용함.
2. 정렬된 Value1, Value2를 기준으로 SELECT 하는일이 더 빈번할것으로 예상됩니다.

박인호님
제가 DB에 대한 지식이 전무해서..
그냥 컴퓨터공학 책에서 나오는 단편화는 알지만 데이터베이스의 단편화는 어떤 단편화인지 궁금합니다.
어떤경로로해서 구멍이 생기는지.. 그게 DB가 인덱스 관리 도중에 생기는 문제인가요?

우욱님
ID값으로 JOIN은 사용을 안하고있어요.
안써도 되는상황이라서요.
하지만 WHERE 절에서 ID 값을 자주사용하는데... 문제될 여지가 많을까요?

추가적으로 제가 인터넷을 찾던중...
인덱스 내부 구조상 한쪽으로 데이터가 삽입될때 한쪽으로 치우칠 수 있다는 글을 봤는데 위와같은 구조면 한쪽으로 치우칠거같은데 맞나요??
 

페이지 조각화에 대한 설명은 showcontig(앞으로 없어지지만 이해를 위한 글이 제일 많이 튀어나오는 검색어)를 검색하셔서 읽어보시면 됩니다.

1. 최초 5건 삽입시
   1. page1: 12345
2. 1건 추가 삽입시
   1. page1: 123
   2. page2: 456
3. 2건 추가 삽입시
   1. page1: 123
   2. page2: 45678
4. 1건 추가 삽입시
   1. page1: 123
   2. page2: 456
   3. page3: 789