Full table sacn을 피하자.
데이터베이스 테이블의 목차를 만들어주는 역할이다. 인덱스를 만들어놓으면 CRUD시 추가적인 작업이 필요없다. 즉 고속의 검색의 목적이다.
데이터베이스의 SELECT에서 where문이나 order by문의 성능향상이 목적이다.
테이블의 1개 이상의 컬럼에 이용하여 인덱스를 등록할 수 있다.
인덱스는 카디널리티가 가장 높은 것을 기준으로 잡는게 좋다.
유저테이블에 이름, 나이, 성별이 있다면 중복이 가장 적은 이름을 추천한다.
where, order by절이 많이 등장하는 컬럼을 적용하자.
? 어떤게 진실인가.
왜냐? 해당 컬럼의 기준으로 트리를 만들게 되는데, 중복이 적은 것으로 사용하게되면 인덱스 자체가 테이블과 크게 다를게 없어진다.
출처 : https://jojoldu.tistory.com/
위는 dept_no
을 기준으로 인덱스를 만들었다. 탐색시 Leaf에 있는 정보들을 바탕으로 디스크를 읽는다. 하지만 leaf의 정보가 분기가 안되어있으면? Full table scan과 차이가 없다.
SELECT name, email FROM oauth_user WHERE oauth_domain='GITHUB'
위와 같은 oauth의 도메인별로 where절을 치는 쿼리가 있다.
인덱스가 되어있지 않으면 oauth_user
의 모든 테이블을 풀 스캔
을 한다.
인덱스가 정렬해놓은 곳을 스캔하면 되기때문에 모든 테이블을 scan할 필요가 없어짐.
⇒ 디스크의 정보를 모두 읽을 필요가 없음.
인덱스 등록하는법
CREATE INDEX [인덱스_이름] ON [테이블_이름] (...테이블의_컬럼)
예시)
CREATE INDEX IDX_USER ON user (address, name, gender);
이렇게하면 해당 컬럼을 사용하는 곳에서 where, join의 성능이 매우 좋아진다.
'그럼 모든 테이블에 인덱스를 걸면 되는거 아니야?' 라고 생각할 수 있다. 인덱스에도 단점이 있다.
클러스터형 인덱스와 비클러스터형 인덱스가 있다.
E모사
Database where Vs Server filter
non clusered index
가 생기는것 같다.
SELECT name, email WHERE oauth_user WHERE oauth_domain='GITHUB'
여기 오타있습니다 ㅎㅎ