제 5절 데이터베이스의 구조와 성능
1. 슈퍼타입/서브타입 모델의 성능고려 방법 -> 데이터의 양 & 트랜잭션의 유형을 파악하여 수행
잘못 설계하면
1) 트랜잭션은 항상 일괄로 처리하는데 테이블은 개별로 유지되어 UNION 연산에 의한 성능저하 가능
2) 트랜잭션은 항상 서브타입으로 처리하는데 테이블은 하나로 통합되어 있어 불필요하게 많은 양의 데이터 집약으로 ~
3) 트랜잭션은 항상 슈퍼+서브 타입을 공통으로 처리하는데 개별, 하나의 테이블로 집약되어 있어 성능 저하
2. 변환기술
1) 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성
- 슈퍼타입과 서브타입에 각각 트랜잭션이 발생할 때는 모두 분리하여 1:1 관계를 갖도록 한다.
2) 슈퍼 + 서브타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼+서브타입 테이블로 구성
-
3) 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성
- 만약 테이블이 개별로 분리된다면 불필요한 조인, 과도한 UNION, UNION ALL로 인해 성능 저하 됨.
1. 인덱스 특성을 고려한 PK/FK DB 성능향상
WHERE 절에서 = 연산을 이용하는 칼럼의 순서를 앞쪽에 위치시킬 것. BETWEEN은 = 뒤쪽에 위치 시킬 것.
2. 물리적인 테이블에 FK제약이 걸려있지 않을 경우 인덱스 미생성으로 인한 성능저하
물리적 테이블에 FK 제약이 걸려있지 않을 경우 인덱스 미생성으로
예) 학사기준(5만건) / 수강신청(500만건) 테이블
물리적으로는 두 테이블 사이의 FK 참조 무결성 관계가 걸려있지 않다.
-> 비록 물리적으로 학사기준과 수강신청이 연결되어 있지 않다고 하더라도 학사기준으로부터 상속받은 FK에 대해 FK 인덱스를 생성함으로써 SQL문장이 조인이 발생할 때 성능저하를 예방할 수 있다.
제 5절 데이터베이스의 구조와 성능
1. 슈퍼타입/서브타입 모델의 성능고려 방법 -> 데이터의 양 & 트랜잭션의 유형을 파악하여 수행
잘못 설계하면
1) 트랜잭션은 항상 일괄로 처리하는데 테이블은 개별로 유지되어 UNION 연산에 의한 성능저하 가능
2) 트랜잭션은 항상 서브타입으로 처리하는데 테이블은 하나로 통합되어 있어 불필요하게 많은 양의 데이터 집약으로 ~
3) 트랜잭션은 항상 슈퍼+서브 타입을 공통으로 처리하는데 개별, 하나의 테이블로 집약되어 있어 성능 저하
2. 변환기술
1) 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성
- 슈퍼타입과 서브타입에 각각 트랜잭션이 발생할 때는 모두 분리하여 1:1 관계를 갖도록 한다.
2) 슈퍼 + 서브타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼+서브타입 테이블로 구성
-
3) 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성
- 만약 테이블이 개별로 분리된다면 불필요한 조인, 과도한 UNION, UNION ALL로 인해 성능 저하 됨.
1. 인덱스 특성을 고려한 PK/FK DB 성능향상
WHERE 절에서 = 연산을 이용하는 칼럼의 순서를 앞쪽에 위치시킬 것. BETWEEN은 = 뒤쪽에 위치 시킬 것.
2. 물리적인 테이블에 FK제약이 걸려있지 않을 경우 인덱스 미생성으로 인한 성능저하
물리적 테이블에 FK 제약이 걸려있지 않을 경우 인덱스 미생성으로
예) 학사기준(5만건) / 수강신청(500만건) 테이블
물리적으로는 두 테이블 사이의 FK 참조 무결성 관계가 걸려있지 않다.
-> 비록 물리적으로 학사기준과 수강신청이 연결되어 있지 않다고 하더라도 학사기준으로부터 상속받은 FK에 대해 FK 인덱스를 생성함으로써 SQL문장이 조인이 발생할 때 성능저하를 예방할 수 있다.
제 5절 데이터베이스의 구조와 성능
1. 슈퍼타입/서브타입 모델의 성능고려 방법 -> 데이터의 양 & 트랜잭션의 유형을 파악하여 수행
잘못 설계하면
1) 트랜잭션은 항상 일괄로 처리하는데 테이블은 개별로 유지되어 UNION 연산에 의한 성능저하 가능
2) 트랜잭션은 항상 서브타입으로 처리하는데 테이블은 하나로 통합되어 있어 불필요하게 많은 양의 데이터 집약으로 ~
3) 트랜잭션은 항상 슈퍼+서브 타입을 공통으로 처리하는데 개별, 하나의 테이블로 집약되어 있어 성능 저하
2. 변환기술
1) 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성
- 슈퍼타입과 서브타입에 각각 트랜잭션이 발생할 때는 모두 분리하여 1:1 관계를 갖도록 한다.
2) 슈퍼 + 서브타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼+서브타입 테이블로 구성
-
3) 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성
- 만약 테이블이 개별로 분리된다면 불필요한 조인, 과도한 UNION, UNION ALL로 인해 성능 저하
1. 인덱스 특성을 고려한 PK/FK DB 성능향상
WHERE 절에서 = 연산을 이용하는 칼럼의 순서를 앞쪽에 위치시킬 것. BETWEEN은 = 뒤쪽에 위치 시킬 것.
2. 물리적인 테이블에 FK제약이 걸려있지 않을 경우 인덱스 미생성으로 인한 성능저하
물리적 테이블에 FK 제약이 걸려있지 않을 경우 인덱스 미생성으로
예) 학사기준(5만건) / 수강신청(500만건) 테이블
물리적으로는 두 테이블 사이의 FK 참조 무결성 관계가 걸려있지 않다.
-> 비록 물리적으로 학사기준과 수강신청이 연결되어 있지 않다고 하더라도 학사기준으로부터 상속받은 FK에 대해 FK 인덱스를 생성함으로써 SQL문장이 조인이 발생할 때 성능저하를 예방할 수 있다.
'노력만이 살길! > SQLD' 카테고리의 다른 글
| SQL 기본 DDL문 (0) | 2021.06.01 |
|---|---|
| 제6절 분산데이터베이스와 성능 (0) | 2021.06.01 |
| 제 4절 대량 데이터에 따른 성능 (0) | 2021.06.01 |
| 제2절 정규화와 성능 + 제3절 반정규화와 성능 (0) | 2021.06.01 |
| 1절. 성능 데이터 모델링 (0) | 2021.06.01 |