Page History
...
동일 데이터라고해도 스캔의 횟수가 달라질수 있습니다.
클러스터 인덱스 VS 논클러스터 인덱스
| 비교 | 클러스터 인덱스 | 논클러스터 인덱스 |
|---|---|---|
| 차이 | 물리적으로 행을 재배열 | 물리적으로 재배열 하지않음 |
| 스캔 방식 |
|
|
| 페이지크기 | 작음 | 큼 |
| 선택도 |
|
|
| 최대갯수 | 테이블당1 | 테이블당 249 |
지정방법 (DB마다 다를수있음) | PRIMARY KEY는자동 | 명시해서 지정 |
| 키의이점 | 데이터 값의 범위가 큼 키가 조인에 자주사용됨 | |
| 장단점 |
| 빈번한수정에 이점이 있다고 볼수없지만, 클러스터 인덱스에비해 이점이있음 |
스캔 범위/방식에따른 실행계획 전략
성능을 위한 스캔 범위 Type은 3가지정도로 요약할수 있습니다.
...
우리가 원하는 집합을 만들기위해, 2개의 테이블만 조작하여 JOIN문을 사용하면 좋겠지만
실제는 그렇지 않습니다.
권한 이양의 죄악
이와같은 실행계획 권한은,SQL문에서 할수 있는게 아니고 RDB에 모든것을 이양해야하고
우리는 단지, 실행계획에 최적화된 SQL문 작성을 위해 노력해야한다는것입니다.
최적화된 실행계획이, 데이터의 변화에 따라 최악으로 변경될수 있다란점도 인지해야하며
최상의 쿼리는, 실행계획이 변하지않는 적당수준의 느린 쿼리문이 될수도 있습니다.
JAP를 통한 튜닝 포인트의 발상변화
JPA에서는 실행계획이 틀어지고, 예측하기 어려운 튜닝포인트를 쿼리중심에서
...
JPA PROXY/영속성 전이등을 사용하여, 어플리케이션 자체에서
DB접근을 최소화하는 전략을 택할수 있으며...있습니다. 이러한것을 사용한다고
- SQL문에따라 달라지는 같은 결과 다른 실행계획
- 테이블의 생성 옵션/데이터량에 따라 달라지는 검색,업데이트 속도
이러한 것을 무시할수 있는게 아닙니다. 반론적으로 어플리케이션 레이아웃에
있는 성능에 관련된 옵션을 사용하기 위해서는 기존 RDB를 더 잘이해해야한다는것입니다.
JPA에서 이루어지는 성능에 관련된 기능을 간단하게 설명을하면...
| No Format |
|---|
User user1 = findByName("Minsu");
User user2 = findByName("Minsu");
user1.GetName()
user2.GetName() |
...