이거 그냥
인덱스를 걸때 여러개를 걸어버리는게 "복합 인덱스"이다.
1) 주문보기
ID가 같으면 같은 주문임
2) 임시테이블 만들고 복붙하기
빠른방법 -> 
SELECT INTO 사용 ㄱㄱ
3) 복합인덱스 추가
이거 두개 세트로 인덱스 걸어주겠다!
4) 인덱스 정보 살펴보기
이렇게 해주면 우리가 만든 인덱스 제대로 들어간거 확인이 가능하다.
< 인덱스 테스트 1 >
핵심은 이렇게 인덱스를 동시에 두개를 걸었을때 도움이 될까? 하는 부분임
그래서 이것이 적용이 되는지 보면은
이렇게 나오고
컨트롤 + L을 눌러보면은
지금 RID LookUp과 Index Seek라고 뜨는데
Index Seek의 예상실행횟수부터 밑에 3개가 1이 뜨는데
간단하게 말하면 GOOD인 경우이다.
이게 뜨는게 Index Seek, Index SCAN이 있는데
SCAN은 Index Full Scan이다 즉 전부 다 찾기 때문에
Bad이다.
< 인덱스 테스트 2 >
하나면 해도 index Seek뜬다. -> GOOD
< 인덱스 테스트 3 >
Table Scan -> BAD 전부다 하나씩 다 스캔을 한 것이다.
-> 인덱스를 활용을 못함
그래서 < 인덱스 테스트 3 > 와같은 문제는 왜 발생하냐면
이렇게 인덱스를 만들어 줄 때 만들어주는 순서와 상관이 있다.
OrderID가 먼저와서 1번이고 그다음에 ProductId라
ORDERID로 찾는거는 가능 but ProductID로만 찾는거는 ㄴㄴ
5) 인덱스 정보
이래 나오는데
트리구조가
920 856 888 889 890 891 892
이런식이다.
데이터 저장 순서 살펴보기
Northwind의 리프노트가 1이고 856페이지 3번옵션으로 출력해주세요 하면은
이래나옴
ORDERId로 먼저 비교하고 ProductId로 비교함
ORDERId가 1순위 ProductId 가 2순위 이다.
따라서 인덱스 (A, B)사용중이라면 인덱스 (A) 없어도 무방
하지만 B로도 검색이 필요하다면은 -> 인덱스 (B)는 별도로 걸어줘야함
6) 인덱스는 데이터가 추가/갱신/삭제 유지되어야함
-> 데이터 50개를 야매로 넣어보고
-> 10248/11 10387/24
이렇게하고
인덱스 정보 다시 살펴보면은
이렇게나오는데
920 856 888 889 890 891 892
원래는 이랬는데 이전에 없던
921가 새로 생겻다.
920 856 [921] 888 889 890 891 892
이렇게 추가가 됨.
그래서 856 페이지에 데이터가 넘치면 다음 데이터를 921에 이어서 갖다 붙이는 형식이다.
결론 : 페이지 여유공간이 없으면 -> 페이지 분할 발생
7) 가공테스트
이렇게 만들어주고
인덱스 만들어준다.
그리고 Bu라는 이름을 가진 사람 찾을때
이렇게하면되는데
보면은 인덱스 스캔이 뜨고있다.
왜> -> 
이런식으로 가공해서 쓰면은 인덱스를 활용을 못할 수 있다.
그래서 Bu로 시작하는 것을 찾고싶다면
LIKE써줘야함
그러면 아무런 문제가 없다.
8) 오늘의 결론
복합인덱스(A, B)를 사용할 때 순서 주의 (A -> B순서 검색)
인덱스 사용시, 데이터 추가로 인해 페이지 여유 공간 없으면 SPLIT
키 가공할 때 주의!
