-
이해를 못해도 흐름을 봐두고 나중에 다시 공부하는것도 좋음
-
DB에서 긁어올 때, 기본적으로 풀 스캔을 하게 된다
- ex 1번 ~ 10000번 까지있으면 다 봐야함 → Data가 많을수록 성능이 떨어진다
- pk, fk 는 시간복잡도가 1? O(N)이다
- fruit index를 만든다? 그리고 정렬을한다
- 이분검색 → binary research
O(N) → O(logN) 시간복잡도를 낮춘다.
인덱싱을하여 읽기기능을 향상시킨다
- CA를 또검색해야한다? Fruite 와 state 를 두개 다 정렬한 인덱싱을 해야한다.
- 만약 여기서 state’CA’만 검색하고 싶다면, 그에 해당하는 테이블만 따로 만들어야한다.
- 변경이나 삽입이 발생하면, 테이블마다 정렬을 맞춰줘야한다.(단점)
- 업데이트의 비율이 많다? 오히려 부적합 할 수 있다.(우리서비스를 고려해야함)
- 워크벤치에 존재하고, SQL문이 따로 존재한다.
-
인덱스라는 자료 구조를 쓰기 위해서, 보통 2개중에서 한개를 쓴다
- 해시테이블 : 자료구조의 특성상 range검색이 안된다
- B+ Tree를 쓴다 : Default로 쓴다
-
실제 사용
- CREATE INDEX idx_test ON Books(writer)
- 모르고쓰냐? 알고쓰냐에 관한 질문을 할 수 있음
- 즉 장단을 파악하는 태도. 얕게쓰냐? 깊게쓰냐?
- 중요한 이유? → 성능에 영향을 끼친다.
-
프로젝트
- 게시글을 불러온다 → 성능향상 테스트
- sql 실행문을 통해 테스트를 해본다
- FULL SCAN VS INDEX
- 추가적인 장점 : Order By (리소스가 많이 든다)
퀵소트 nlogn 들어간다.
- 정렬되어있는 인덱스를 가져오라 → ex)랭킹페이지
-
실제 테스트는 어떻게 하나?
- 테스트 툴을 이용할 수도 있다.
- 충분히 미숙할 수 있다
- database procedure : 내장함수가 있다
-
자기에게 맞는 학습법을 시작하자
- 현업에서는 빠르게 학습해야한다 → 어떤방식으로 학습하는지가 중요하다.
- 직접 부딪힌다.
- 책을 사는사람도 있다.
- 나에 대해서 알아가는 것도 중요하다.
