Index Scan 인덱스 스캔

모든 검색의 기본은 '풀스캔'
검색을 빠르게 하려면 '중복 데이터가 없어야 한다'
중복이 있다면 정렬해서 '군집화' 시켜야 한다.

[ 풀스캔 ]

풀스캔 시, 시간복잡도는 O(n)
(책으로 비유했을 때, n은 페이지 개수라고 생각하면 된다. 
 만약, n이 100p면 무조건 100이 나온다. 100장을 넘겨야 하기 때문...)

시간복잡도는 평균을 보는 것. 제일 재수 없는 걸(최악을) 본다!

만약, 시간복잡도가 O(n)/2 이면, 100p가 있다고 가정했을 때,
평균적으로 50장만 넘기면 다 찾을 수 있다는 뜻! (이 경우엔 최악이 50p 인 듯)

[ 인덱스를 만들면 다른 일이 일어남 ] - 랜덤 액세스

인덱스를 만든다 = 책에 목차를 만든다. / (index를 검색하는 시간이 1번으로 든다.)

랜덤 액세스를 하면 시간복잡도가 완전 달라진다
다이렉트하게 찾을 수 있어서 한방에 끝나기 때문!!

중복이 되어있다고 해도, 인덱스가 있으면 목차에서 보고 넘기면 되니까 빠르다.
그러나, 무조건 빠른게 아니다.

요리책의 100p 중 80p가 전부 다 국물 요리면 풀스캔이 낫다.
인덱스 보고, 국물 요리 찾고, 인덱스 보고, 국물 요리 찾고, 인덱스 보고, 국물 요리 찾고...
-> 왔다갔다 하니까 차라리 풀스캔이 더 빠르다!

내가 찾는 비중이 15% 이하면 무조건 인덱스가 효율이 좋다!
(100p중 15p 이하면 인덱스로 하는게 더 빠르다) 

DB에서 내가 PK를 설정하면, PK는 유일하기 때문에 무조건! 15%가 아니다.
데이터가 100개 있으면 (유일키라 1개만 있으니까) 1%
PK를 만들면 자동으로 인덱스를 다 달아준다

username을 검색할 때는 인덱스를 단다. 
PK는 랜덤 액세스!!

title은 중복될 수 있고, 내가 기획할 수 있는게 아니다. (사람들이 적으니까)
PK 절대 아니겠지

[ 인덱스를 사용하면 좋은 경우 ]

[ PK에다 ORDER BY 걸면 별로 안 좋다 ]

PK가 INDEX니까, INDEX를 거꾸로 읽으면 정렬이 끝난다. 그래서 ORDER BY는 안쓰는 듯
애초에 INDEX는 정렬해서 들어가기 때문에 ORDER BY가 의미없다는 것 같다.

지금은 그냥 ORDER BY ㄱㄱ

[ ORDER BY 대신 INDEX HINT를 사용하자 ]

ORDERY BY 대신 INDEX 힌트를 사용하자 <- 구글링
[ + = HINT ] JVM의 어노테이션 같은 것