. 인덱스(INDEX)를 몰랐던 나

처음 SQL Server를 접한 것은 버젼 6.5였습니다. 업체에서 설치해 주고 간 SQL Server에 내가 아는 오직 한가지 CREATE TABLE을 이용해서 테이블을 만들었습니다. 그리고 이런 방법 저런 방법을 이용해서 IBM AS/400에서 데이터를 이 테이블로 내려 부었습니다. 다운사이징이 되었다는 기쁨에 Visual Basic을 이용해서 데이터를 조회하는 Application을 작성했습니다.
"으헥~이게 뭐야. 차라리 Access가 났겠구만~"
너무나 느렸습니다. 조회 버튼 누르고 수 분이 걸려야 결과가 나왔습니다. 하지만 관련 서적을 뒤적이다 인덱스의 존재를 알고 이를 반영하고 나니 모든게 달라졌습니다.
"으와~진짜 빠르다!"

2. 인덱스를 만드는 이유

인덱스를 만드는 이유는 가장 큰 이유가 데이터를 빠르게 검색하기 위함 입니다. 베개만한 두께의 SQL Server 참고서적이 있다고 할 때 이 책에서 CONSTRAINT에 대한 내용을 찾고자 한다면 우리는 책 전체를 뒤지는게 아니고 책 뒤의 인덱스 부분을 참조하여 CONSTRAINT가 위치한 페이지를 확인하고 그 페이지로 이동하여 원하는 내용을 참조하게 됩니다. 데이터 검색도 마찬가지 입니다. 인덱스가 없다면 테이블 전체를 읽어 원하는 데이터를 찾아야 합니다.

인덱스를 만드는 두번째 이유는 Row의 유일성을 유지하기 위한 것입니다. UNIQUE 인덱스가 여기에 해당합니다. 예를 들어 사원 테이블에는 동일한 사원번호를 갖는 사원 정보가 있어서는 안됩니다. 이런 경우 사원번호에 인덱스를 이용하여 유일성을 부여할 수 있습니다.

3. 인덱스의 안좋은 점

인덱스가 좋다고 무작정 좋은 것은 아닙니다. 인덱스를 만들게 되면 그 정보를 유지하기 위해서 디스크 공간도 필요하게 되고, 인덱스가 걸려 있는 테이블은 인덱스가 없을 때보다 데이터를 추가하거나 변경할 때 너 많은 시간이 소요 됩니다. 이런 이유로 인덱스를 만들 때 해당 테이블의 용도를 정확히 이해해야 합니다. 만일 읽기 전용의 테이블이라면 인덱스를 걸어 주는게 좋고, 수정 및 추가가 엄청나게 이루어지는 테이블이라면 인덱스 거는것이 역효과가 날 수 있습니다. 처음 인덱스를 알게 된 저는 이런 사실을 모르고 무작정 인덱스를 만들었습니다. 결국엔 모든 컬럼에 인덱스가 걸려 배보다 배꼽이 더 커져버린 결과가 되었습니다.

4. 인덱스의 종류

인덱스의 종류를 굳이 나누자면 다음의 두가지로 분류 할 수 있습니다.

o Clustered Index
o Nonclustered Index

Clustered Index 는 영어 사전을 생각하시면 쉽게 이해 할 수 있습니다. 영어 사전은 자체가 알파벳 순서로 정렬 되어 있기 때문에 우리가 찾고자 하는 단어를 쉽게 찾을 수 있습니다.

Nonclustered Index는 책 뒤에 있는 인덱스를 생각하지면 됩니다. 책 여기 저기에 흩어진 내용을 이 인덱스를 이용하면 그 위치(페이지)를 쉽게 찾을 수 있습니다.

인덱스는 SQL Server Performance 튜닝에 있어서 가장 기본적인 것입니다. 물론 비싼 돈을 드려 빵빵한 서버를 구축하는 것도 성능 향상을 꾀하는 방법이긴 하지만 돈 안들이고 성능을 향상 시키는 방법, 그것이 인덱스 입니다. 앞으로 꽤 많은 강좌가 인덱스를 설명하게 위해 할애될 것 같습니다. 자 시작해 볼까요?

5. 연습용 테이블 만들기

우선 다음과 같은 구조의 Customers 테이블을 만들었다고 가정을 하겠습니다.

CREATE TABLE Customers ( cust_id char(05) NOT NULL , cust_name varchar (40) NOT NULL , phone char (12) NOT NULL , address varchar (40) NULL )

6. PRIMARY KEY를 지정할 때 생성되는 인덱스

앞에서 만들어진 Customers 테이블에 cust_id 컬럼을 Primary Key로 지정하고자 다음과 같이 수행하였습니다.

ALTER TABLE Customers ADD CONSTRAINT PK_Customers PRIMARY KEY (cust_id) GO

이와 같이 Primary Key를 만들게 되면 자동적으로 PK_Customers라는 이름의 인덱스가 생성이 됩니다. 인덱스의 종류를 지정하지 않은 경우 Primary Key 생성시에는 기본적으로 Clustered Index 가 됩니다. 또한 Primary Key는 유일성을 보장하는 것이므로 Unique Index가 됩니다. 만일 Primary Key를 만들 때 Nonclustered Index가 되게 하고자 한다면 다음과 같이 NONCLUSTERED라고 지정해야 합니다.

ALTER TABLE Customers ADD CONSTRAINT PK_Customers PRIMARY KEY NONCLUSTERED (cust_id) GO

생성된 인덱스의 존재를 확인하고자 한다면 다음과 같이 sp_helpindex 를 이용하면 됩니다.

sp_helpindex Customers

7. PRIMARY KEY가 꼭 Clustered Index가 될 필요는 없습니다.

앞에서 확인했다시피 별도의 지정이 없으면 Primary Key는 Clustered Index가 됩니다. 이런 이유로 많은 분들이 Primary Key는 항상 Clustered Index라고 생각하시는 경우가 있는데 그렇지 않습니다. 필요한 경우 Primary Key를 Nonclustered Index 로 하고 별도의 Clustered Index를 만들수 있습니다.

다음의 예는 Customers 테이블에서 cust_name에 Clustered Index를 생성하는 것입니다.

CREATE CLUSTERED INDEX CL_cust_name ON Customers (last_name)

o 인덱스를 만들 때는 CREATE INDEX 문을 이용합니다.
o CL_cust_name 이 인덱스 이름이 됩니다.
o Customers (last_name) 은 Customers 테이블의 last_name 컬럼을 지정하는 것입니다.

주의 할 것은 Clustered Index는 한 테이블에 오직 한개만 존재 할 수 있다는 사실입니다.

8. 인덱스 만들기(CREATE INDEX)

앞의 강좌에서 마지막 부분에 잠깐 언급을 했듯이 인덱스를 만들 때는 CREATE INDEX 문을 사용합니다. 물론 Enterprise Manager를 이용해서 인덱스를 만드는 방법도 있지만 여기서 다루지는 않겠습니다.

다음은 인덱스에 대한 숫자적인 제약입니다.

o Clustered Index는 한테이블에 오직 한개만 가능
o Nonclustered Index는 한 테이블에 249개 까지 가능
o 한 인덱스에 포함 될 수 있는 컬럼은 최대 16개까지

보통 현업에서 한 테이블에 인덱스가 5개 정도 됩니다. 그러므로 249개까지 가능하다는 것은 실무에는 별 의미가 없다고 생각합니다. 컬럼이 16개나 인덱스에 포함될 경우도 거의 없습니다. 인덱스를 만들 때 어떤 인덱스를 만들지 결정을 해야 합니다. 즉 Clustered Index로 할지 Nonclustered Index로 할 지, Unique 를 지정할지 말지를 결정해야 합니다. 이를 결정하기 위해서는 해당 테이블이 어떠한 용도로 사용되는지 업무를 정확히 파악을 하고 있어야 합니다. 인덱스를 만드는 방법은 너무나 간단합니다. 하지만 인덱스를 어떻게 만들 것인지 결정하는 것은 그리 쉬운 일이 아닙니다. 많은 고민이 필요합니다.

예제를 보면서 인덱스를 만드는 방법을 확인해보도록 하겠습니다.

[예제1]

CREATE INDEX idx1 ON Customers(cust_id)

o 어떤 종류의 인덱스를 만들지 설정되지 않았습니다.
o 이런 경우 기본적으로 Unique 하지 않은 Nonclustered Index가 됩니다.

[예제2]

CREATE CLUSTERED INDEX idx1 ON Customers(cust_id)

o 인덱스 종류는 Clustered로 지정 되었으므로 Clustered Index가 만들어집니다.
o 하지만 Unique는 지정되지 않았습니다. 이런 경우 [예제 1] 처럼 Unique 하지 않은 Index가 됩니다.

[예제3]

CREATE UNIQUE INDEX idx1 ON Customers(cust_id)

o Unique 한 Nonclustered Index 가 만들어집니다.

[예제4]

CREATE UNIQUE CLUSTERED INDEX idx1 ON Customers(cust_id)

o Unique 한 Clustered Index 가 만들어집니다.

[예제5]

CREATE CLUSTERED UNIQUE INDEX idx1 ON Customers(cust_id)

o 오류가 발생합니다.
o UNIQUE는 CLUSTERED 나 NONCLUSTERED 앞에 위치해야 합니다.

9. Nonclustered Index 구조

꼭 인덱스 구조를 알고 있을 필요는 없지만 알아두면 피가 되고 살이 되기 때문에 간단하게 언급을 하고자 합니다. 아래 이미지는 Books Online에 있는 이미지입니다. 이 이미지를 보면서 몇가지 사항을 확인해보도록 하겠습니다.

인덱스는 위 이미지와 같이 B-트리 구조로 되어 있습니다. 마치 나무를 거꾸로 세워놓은 듯한 구조이기 때문에 위처럼 뿌리(root)가 보이고 잎이 보입니다.

1) sysindexes 시스템 테이블

sysindexes 테이블에는 인덱스에 대한 정보가 기록되어 있습니다. 인덱스 정보를 기록하고 있는 실제 인덱스 페이지가 어디에 있는지 인덱스의 종류가 무엇인지 등이 포함되어 있습니다. 나중에 기회가되면 자세히 확인해보도록 하겠습니다.

2) 용어설명

o 루트노드(Root node) : 인덱스는 위 이미지처럼 나무를 꺼꾸로 세워놓은듯(그렇게 안보이나요?)한 모양을 하고 있는 트리구조(B-트리구조라고 부릅니다)로 되어 있는데 이 트리의 시작을 Root node라고 합니다. 모든 인덱스 검색은 이 Root nodel에서 시작됩니다.

o 잎노드: 보통 Leaf Level이라고 부릅니다. 위의 이미지는 너무 단순해서 모양이 나타나지 않지만 하나의 뿌리에서 자라나온 가지에 마지막으로 달린 잎같다고 해서 Leaf Level이라고 부릅니다. Nonclustered Index에서는 이 Leaf Level에 실제 데이터가 존재하는 포인터가 기록되어 있습니다.(Clustered Index에서는 이 Leaf Level이 Data Level이 됩니다)

o 중간노드 : 보통 Non-Leaf Level 이라고 부릅니다. 위 이미지에서는 표시되지 않았지만 Root node와 Leaf Level사이에 더 많은 인덱스 페이지가 있을 수 있습니다. 이를 Non-Leaf Level 이라고 부릅니다.

o 데이터 페이지 : 실제 데이터가 저장되는 페이지를 Data Page라고 합니다.

10. UNIQUE 인덱스 만들기

인덱스를 만드는 이유가 대부분은 검색 속도를 빠르게 하기 위함이라고 생각하고 있습니다. 이게 틀린 말은 아니지만 인덱스를 만드는데는 유일성을 유지하여 데이터 무결성을 구현한다는 중요한 목적도 포함되어 있습니다. 물론 UNIQUE 제약을 이용해서 이를 구현 할 수 있지만 CREATE INDEX 문을 이용해서도 가능합니다. 사실 PRIMARY KEY나 UNIQUE 제약을 설정하면 내부적으로 자동적으로 UNIQUE 인덱스가 만들어 집니다.

UNIQUE인덱스에 대한 몇가지 특징을 살펴 보겠습니다.

o PRIMARY KEY나 UNIQUE 제약을 설정하면 자동적으로 UNIQUE 인덱스가 만들어집니다.
o 만일 테이블에 데이터가 존재하는 상태라면 UNIQUE 인덱스를 만들 때 중복되는 값이 있는지 체크 합니다. 만일 중복된 값이 있다면 UNIQUE 인덱스를 만들수 없습니다.
o UNIQUE 인덱스가 설정되어 있으면 INSERT나 UPDATE시 데이터 값의 중복 여부를 확인해서 중복되면 값을 받아들이지 않고 에러메세지를 표시합니다.

[예제1]

CREATE TABLE A ( col1 CHAR(2), col2 INT) GO INSERT INTO A VALUES ('AA',123) INSERT INTO A VALUES ('AA',345) GO CREATE UNIQUE INDEX IDX1 ON A(col1) GO

o 두번의 INSERT에 의해서 col1에는 'AA'라는 중복된 값이 입력된 상태에서 UNIQUE 인덱스를 생성하려고 했습니다.
o 이 경우 다음과 같은 오류가 발생하면서 UNIQUE 인덱스를 만들지 못합니다.

서버: 메시지 1505, 수준 16, 상태 1, 줄 1 인덱스 ID 2에 중복 키가 있어 CREATE UNIQUE INDEX가 종료되었습니다. 가장 중요한 기본 키는 'AA'입니다. 문이 종료되었습니다.

[예제2]

CREATE TABLE B ( col1 CHAR(2), col2 INT) GO CREATE UNIQUE INDEX IDX1 ON B(col1) GO INSERT INTO B VALUES ('AA',123) INSERT INTO B VALUES ('AA',345) GO

o col1 컬럼에 대하여 UNIQUE 인덱스를 만든 상황에서 중복되는 값 'AA'가 INSERT되려고 합니다.
o 두번째 INSERT문은 다음과 같은 오류가 발생하면서 INSERT가 거부됩니다.

서버: 메시지 2601, 수준 14, 상태 3, 줄 1 고유 인덱스 'IDX1'이(가) 있는 'B' 개체에 중복 키 행을 삽입할 수 없습니다. 문이 종료되었습니다.

o Unique 한 Clustered Index 가 만들어집니다.

[예제3]

CREATE TABLE AA ( col1 CHAR(2), col2 INT) GO INSERT INTO AA VALUES ('AA',123) INSERT INTO AA VALUES ('AA',345) CREATE TABLE BB ( col1 CHAR(2), col2 INT) GO CREATE UNIQUE INDEX IDX1 ON BB(col1) GO INSERT INTO BB SELECT * FROM AA

마지막 INSERT문에 의해서 테이블 BB에는 몇개의 레코드가 INSERT 될까요?

[예제3]

CREATE TABLE AA ( col1 CHAR(2), col2 INT) GO INSERT INTO AA VALUES ('AA',123) INSERT INTO AA VALUES ('AA',345) CREATE TABLE BB ( col1 CHAR(2), col2 INT) GO CREATE UNIQUE INDEX IDX1 ON BB(col1) GO INSERT INTO BB SELECT * FROM AA

o 마지막 INSERT문에 의해서 테이블 BB에는아무 레코드도 INSERT 되지 못합니다.
o 처음 한 레코드가 INSERT되고 두번째 레코드가 INSERT 되려고 할 때 중복 값이 확인되어 모든 처리가 취소되어 버립니다.

[예제4]

CREATE TABLE AA ( col1 CHAR(2), col2 INT) GO INSERT INTO AA VALUES ('AA',123) INSERT INTO AA VALUES ('AA',345) CREATE TABLE BB ( col1 CHAR(2), col2 INT) GO CREATE UNIQUE INDEX IDX1 ON BB(col1) WITH IGNORE_DUP_KEY GO INSERT INTO BB SELECT * FROM AA

o CREATE UNIQUE 문에 WITH IGNORE_DUP_KEY 옵션이 포함되어 있습니다. 이는 레코드가 입력이 될 때 중복된 값은 받아 들이지 않더라고 나머지는 받아들이라는 설정입니다.
o 처음 한 레코드가 INSERT되고 두번째 레코드가 INSERT 되려고 할 때 중복 값이 확인되어 두번째 INSERT는 무시되고 처음의 INSERT는 반영이 됩니다. 하지만 다음과 같은 메세지는 표시됩니다.

서버: 메시지 3604, 수준 16, 상태 1, 줄 1 중복 키가 무시되었습니다.

[예제5]

SELECT col1, COUNT(col1) FROM AA GROUP BY col1 HAVING COUNT(col1) > 1 ORDER BY col1

o UNIQUE 인덱스를 만들기전에 중복되는 값이 있나 확인하는 방법입니다.
o 간단한 쿼리문이지만 참으로 유용하게 사용됩니다. 이해하기 어려운 것이 아니므로 자세한 설명은 생락합니다.

11. COMPOSITE 인덱스

하나의 컬럼에 대하여 인덱스를 만들라는 제약은 없습니다. 필요한 경우 여러개의 컬럼을 대상으로 인덱스를 만들 수 있습니다. 이와 같은 인덱스를 COMPOSITE 인덱스라고 합니다. COMPOSITE 인덱스에는 최대 16개까지의 컬럼을 포함 시킬 수 있지만 실무에서는 많아야 3~4개 정도의 컬럼이 사용됩니다. COMPOSITE 인덱스를 만들어야 하는 경우는 다음의 두가지로

우선 다음의 예를 보도록 하겠습니다.

[예제1]

CREATE TABLE Customer ( cust_id CHAR(5), cust_name CHAR(10), city CHAR(6), grade CHAR(1)) GO SELECT * FROM Customer WHERE city = '서울' AND grade = 'A' GO

o SELECT문에서 WHERE부분에 city와 grade 두 컬럼을 비교하고 있습니다.
o 이러한 검색이 성능이 좋게 하고자 한다면 다음과 같이 COMPOSITE 인덱스를 만들어주면 됩니다.

CREATE INDEX idx1 ON Customer (city, grade) GO

o 앞에서 배운것 복습해 볼까요? UNIQUE가 설정되지 않았고 CLUSTERED 여부도 설정되지 않았습니다. 그렇다면 UNIQUE 하지 않은 NONCLUSTERED 인덱스가 만들어집니다. 기억하시죠?
o 컬럼을 지정하는 부분에 city, grade 두 컬럼이 나열되어 있습니다. 이것이 COMPOSITE 인덱스를 만드는 방법입니다.

여기서 한가지 의문이 생깁니다. 인덱스를 구성하는 컬럼의 순서가 city, grade 인것과 grade, city 인것 두가지가 동일한 성능을 제공할까 하는 것과, 만일 다르다면 어떤 순서가 더 나은 성능을 제공할까 하는 의문입니다.

o 인덱스를 구성하는 컬럼의 순서가 다르다면 그 효과역시 다릅니다.
o 인덱스를 구성하는 컬럼의 순서를 결정하는 것은 테이블의 데이터에 달려 있습니다.
o 만일 위 [예제 1]의 Customer 테이블에서 city 컬럼과 grade 컬럼중 어느것이 선택성(Selectivity)가 좋은지에 따라 컬럼의 순서를 정해야 합니다. 예를 들어 전체 레코드가 10,000개이고, 이중에서 city = '서울'의 조건을 만족하는 레코드가 1,000개이고 grade = 'A'를 만족하는 레코드가 100개라면 인덱스를 구성하는 컬럼의 순서는 grade, city 가 되어야 한다는 것입니다. 즉 다음과 같이 인덱스를 만들어야 합니다.

CREATE INDEX idx1 ON Customer (grade, city) GO

o WHERE 절도 마찬가지 입니다. 선택성이 좋은(다시 말하면 UNIQUE 한 값이 많은) 컬럼을 앞으로 가져와야 더 나은 성능을 제공 받을 수 있습니다.

※ 선택성(Selectivity)

여기 1부터 1,000까지의 숫자가 있습니다. 1, 2, 3, 4, 5 . . . . . .555, 556, 557. . . . . . 997, 998, 999, 1000 ① 이 중에서 2의 배수는 500개 입니다. ② 이 중에서 5의 배수는 200개 입니다. ③ 이 중에서 10의 배수는 100개 입니다. ④ 이 중에서 100의 배수는 10개 입니다. ⑤ 이 중에서 1000의 배수는 1개입니다. 위 결과로 볼 때 선택성이 가장 좋은 것은 ⑤번 입니다. 가장 선택성이 않좋은 것은 ① 번 입니다. 즉, 검색한 결과가 전체 데이터에서 차지하는 비율이 낮을 때 선택성은 좋다고 이야기 합니다. 이러한 컬럼들이 인덱스를 구성하는 컬럼의 후보가 됩니다.

12. FILLFACTOR & PAD_INDEX

테이블에 데이터가 INSERT 되거나 UPDATE되면(즉 데이터 페이지에 변경이 생기면) 인덱스 페이지 역시 변경이 됩니다. 데이터 페이지에 추가되는 데이터는 빈공간을 찾아 또는 뒷부분에 자리를 잡는다 하더라도 인덱스 페이지는 인덱스 키값에 의해 순서적으로 위치해야 하므로 자신의 자리를 찾아 삐집고 들어가게 됩니다. 이때 인덱스 페이지가 꽉 찬 상태가 아니고 여유 공간이 있다면 기존의 데이터를 뒤로 밀치고 자기 자리를 찾을 수 있지만, 새로운 데이터가 위치해야될 인덱스 페이지가 꽉찬 상태라면 삐집고 들어갈 공간이 없게 됩니다. 이러한 경우 해당 인덱스 페이지가 절반으로 나뉘게 되어 나뉘어진 뒷부분의 데이터는 새로운 페이지로 옮겨지게 되고 추가되려던 데이터는 자기 자리를 잡게 됩니다. 이러한 것을 페이지 분열(Page Split) 이라고 합니다.

위 사실로 볼 때 계속적으로 데이터가 추가되거나 변경되게 되면 인덱스 페이지의 데이터들은 순서대로 위치하기 위해 수많은 페이지 분열이 일어나게 되며, 이러한 결과로 INSERT 및 UPDATE 성능이 느려지게 됩니다. 이러한 문제를 방지하기 위해 우리가 할 수 있는 일은 인덱스 페이지를 꽉 차지 않게 여유 공간을 두어 페이지 분열이 일어나지 않도록 하는 것입니다. 이때 사용되는 것이 FILLFACTOR 입니다.

o FILLFACTOR는 인덱스 페이지를 어느정도 채울 것인지 지정하는 것입니다.
o FILLFACTOR를 이용하여 충분히 인덱스 페이지를 비워둠으로써 페이지 분열을 막아 INSERT 및 UPDATE 성능이 향상되게 됩니다.
o INSERT나 UPDATE가 이루어지지 않는 경우하면 굳이 FILLTACTOR를 사용할 필요가 없습니다. 필요가 없다기보다 사용하지 않는것이 더 좋습니다. 되도록 데이터가 서로 서로 붙어 있어야 빨리 읽을 수 있으니까요.

그러므로 FILLFACTOR를 지정할 때는 테이블의 용도를 정확히 파악하고 있어야 합니다.

※ 인덱스 페이지에는 Leaf Level과 Non-leaf Level이 있습니다. FILLFACTOR만 사용하면 Leaf Level 인덱스 페이지의 페이지 분열을 막는 역할만을 하게됩니다. 만일 Non-Leaf Level에도 적용하고자 한다면 PAD_INDEX와 같이 사용해야 합니다.

다음은 FILLFACTOR에 대한 몇가지 정보입니다.

o FILLFACTOR 값은 1 부터 100까지 입니다.
o 별도의 FILLFACTOR를 지정하지 않으면 기본값 0 이 설정되어 Leaf Level 인덱스 페이지는 100% 꽉 차게 됩니다.
o 원한다면 sp_configure 시스템 저장 프로시져를 사용하여 기본값을 변경 할 수 있습니다.
o FILLFACTOR 값은 어느정도 인덱스 페이지를 비울것인가가 아니고 어느정도 채울 것인가를 지정하는 것입니다.
o 처음 지정한 FILLFACTOR는 계속 유지되는 것이 아닙니다. 비워두었던 인덱스 페이지도 데이터가 계속 추가됨에 따라 꽉 차게되면 역시 페이지 분열은 이러나게 됩니다. 이런 이유로 매일 새벽 스케줄을 이용하여 적당한 FILLFACTOR값을 이용하여 인덱스를 다시 만들어 주는 경우가 있습니다.

기억하세요! FILLFACTOR는 FILLFACTOR를 이용하여 인덱스를 처음 만들어 주거나 다시 만들어 줄때만 효과가 있다는 것을.

[예제1]

CREATE INDEX idx1 ON Customer(cust_id) WITH FILLFACTOR = 70

o FILLFACTOR값을 70으로 지정했으므로 Leaf Level 인덱스 페이지는 70% 만 채워지고 30%는 비워두어 페이지 분열을 막아줍니다.

[예제2]

CREATE INDEX idx1 ON Customer(cust_id) WITH PAD_INDEX, FILLFACTOR = 70

o PAD_INDEX를 사용하였으므로 Leaf Level 뿐만 아니고 Non-leaf Level 인덱스 페이지고 FILFACTOR값을 적용받게 됩니다.

만일 PAD_INDEX를 사용하지 않으면 Non-leaf Level 인덱스 페이지는 꽉차지는 않고 한개의 데이터가 들어올 수 있는 공간을 남겨두게 됩니다.

----------------------------------------------------------------------------------------

출처 : http://www.sqlworld.pe.kr