:: 작업장

[SQLD] 2과목 SQL 기본및 활용 - 1장 1절 관계형 데이터베이스 개요

1. 데이터베이스

- 특정 기업이나 조직 또는 개인이 필요에 의해 데이터를 일정한 형태로 저장해 놓은 것.

* 데이터베이스의 발전

- 1960년대: 플로우 차트 중심의 개발 방법을 사용하였으며 파일 구조를 통해 데이터를 저장하고 관리하였다.

- 1970년대: 데이터베이스 관리기법이 처음 태동되던 시기였으며 계층형 데이터베이스, 망형 데이터베이스 같은 제품들이 상용화 되었다.

- 1980년대: 현재 대부분의 기업에서 사용되고있는 관계형 데이터베이스가 상용화 되었으며 Oracle, Sybase, DB2와 같은 제품이 있다.

- 1990년대: Oracle, Sybase, Informix, DB2, Teradata, SQL Server외 많은 제품들이 보다 향상된 기능으로 정보시스템의 확실한 핵심 솔루션으로 자리잡게 되었으며 인터넷 환경의 급속한 발전과 객체지향 정보를 지원하기 위해 객체 관계형 데이터베이스로 발전하게되었다.

* 관계형 데이터베이스

- 관계형 데이터베이스는 정규화를 통한 합리적인 테이블 모델링을 통해 이상 현상을 제거하고 데이터중복을 피할 수 있으며 동시성관리, 병행제어를 통해 많은 사용자들이 동시에 데이터를 공유 및 조작할 수 있는 기능을 제공한다.

- 관계형 데이터베이스는 메타 데이터를 총괄 관리할 수 있기 때문에 데이터의 성격, 속성 또는 표현 방법 등을 체계화할 수 있고, 데이터 표준화를 통한 데이터 품질을 확보할 수 있는 장점을 가지고 있다.

- 테이블 생성시에 사용할 수 있는 다양한 제약조건을 이용하여 사용자가 실수로 조건에 위배되는 데이터를 입력한다든지 관계를 연결하는 중요한 데이터를 삭제하는 것을 방지하여 무결성을 보장할 수 있다.

2. SQL

- 관계형 데이터베이스에서 데이터 정의 데이터 조작, 데이터 제어를 하기위해 사용하는 언어.

3. TABLE

- 데이터는 관계형 데이터베이스에서 테이블 형태로 저장된다.

- 모든 자료는 테이블에 등록되고 우리는 테이블로부터 원하는 자료를 꺼내올 수 있다.

- 테이블은 어느 특정한 주제와 목적으로 만들어지는 일종의 집합이다.

- 테이블은 데이터를 저장하는 객체로서 관계형 데이터베이스의 기본단위이다.

- 세로방향은 컬럼, 가로방향은 로우 라고하며 칼럼과 행이 겹치는 부분을 필드라고한다.

- 선수와 관련된 데이터는 선수테이블과 구단 테이블 이라는 복수의 테이블로 분할하여 저장한다.

분할된 테이블은 그 칼럼의 값에 의해 결정된다.  이렇게 테이블을 분할하여 데이터의 불필요하는 중복을 줄이는 것을 정규화라고 한다.

- 각 행을 한가지 의미로 특정할 수 있는 한 개 이상의 칼럼을 기본키(Primary Key)라고 하며 다른 테이블의 기본 키로 사용되면서 테이블과의 관계를 연결하는 역할을 하는 칼럼을 외부키라고 한다.

4.  ERD

- ERD의 구성요소는 엔터티, 관계, 속성 3가지 이며 이 3가지 구성요소로 모두 표현이 가능하다.

[SQLD] 1과목 데이터 모델링의 이해 - 2장 6절:분산 데이터베이스와 성능

1. 분산 데이터베이스의 개요.

- 여러 곳으로 분산되어있는 데이터베이스를 하나의 가상 시스템으로 사용할 수 있도록 한 데이터베이스

- 논리적으로 동일한 시스템에 속하지만, 컴퓨터 네트워크를 통해 물리적으로 분산되어있는 데이터들의 모임, 물리적 SITE 분산, 논리적으로 사용자 통합 공유.

=> 데이터베이스를 연결하는 빠른 네트워크 환경을 이용하여 데이터베이스를 여러 지역 여러 노드로 위치시켜 사용성/성능을 극대화 시킨 데이터베이스.

2. 분산데이터베이스의 투명성.

- 분산데이터베이스가 되기 위해서는 6가지 투명성을 만족시켜야 한다.

1) 분할투명성(단편화) : 하나의 논리적인 Relation이 여러 단편으로 분할되어 각 단편의 사본이 여러 site에 저장.

2) 위치 투명성 : 사용하려는 데이터의 저장 장소 명시 불필요, 위치정보가 system catalog에 유지되어야함.

3) 지역사상 투명성 : 지역 dbms와 물리적 db 사이의 mapping 보장. 각 지역시스템 이름과 무관한 이름 사용가능.

4) 중복 투명성 : DB객체가 여러 site에 중복되어있는지 알 필요가 없는 성질.

5) 장애 투명성 : 구성요소(DBMS, Computer)의 장애에 무관한 Transaction의 원자성 유지

6) 병행 투명성 : 다수 Transaction 동시 수행시 결과의 일관성 유지. Time stamp, 분산2단계 Locking을 이용해서 구성.

3. 분산데이터베이스의 적용방법 및 장단점.

가. 분산데이터베이스의 적용방법

- 업무의 흐름을 보고 업무 구성에 따른 아키텍쳐 특징에 따라 데이터베이스를 구성.

나. 분산 데이터베이스의 장단점

4. 분산 데이터베이스의 활용 방향성

- 위치 중심의 분산설계

- 업무필요에 의한 분산설계

5. 데이터베이스 분산구성의 가치

- 통합데이터베이스에서 제공할 수 없는 빠른 성능을 제공.

- 원거리 또는 다른 서버에 접속하여 처리하므로 인해 발생되는 네트워크 부하 및 트랜잭션 집중에 따른 성능저하이 원인을 분산데이터베이스 환경을 구축하므로 빠른 성능을 제공하는것이 가능해진다.

6. 분산데이터베이스의 적용기법.

가. 테이블 위치 분산

- 테이블 위치분산은 테이블의 구조는 변하지 않는다.

- 다른 데이터베이스에 중복되어 생성되지도 않는다

- 테이블별 위치 분산은 정보를 이용하는 형태가 각 위치별로 차이가 있을 경우에 이용한다.

- 테이블의 위치가 위치별로 다르므로 테이블의 위치를 파악할 수 있는 도식화된 데이터베이스 문서가 필요하다.

나. 테이블 분할 분산

- 테이블 분할 분산은 위치만 다른곳에 놓는것이 아니라 각각의 테이블을 쪼개어 분산하는 방법이다.

- 테이블을 분할하여 분산하는 방법은 테이블을 나누는 기준에 따라 두 가지로 구분된다.

1) 수평분할

- 테이블의 로우단위로 분할.

- 칼럼은 분리하지 않는다.

- 모든데이터가 각 지사별로 분리되어 있는 형태를 가진다.

- 각 지사에 있는 데이터와 다른지사에 있는 데이터와 항상 배타적으로 존재하며 한군데 집합시켜도 Primary key에 의해 중복이 발생하지않는다.

- 수평분할을 이용하는 경우는 각 지사별로 사용하는 Row가 다를 때 사용한다.

- 데이터를 수정할 때는 타 지사에 있는 데이터를 원칙적으로 수정하지 않고 자신의 데이터에 대해서 수정하도록한다.

- 각지사에 존재하는 테이블에 대해서 통합처리를 해야하는 경우 조인이 발생하게 되므로 성능저하가 예상된다. 그러므로 통합처리 프로세스가 많은지 검토 후 많지않은 경우에 수평분할을 한다.

2)수직분할

- 지사에 따라 칼럼을 기준으로 칼럼을 분리한다. 로우단위로는 분리되지 않는다.

- 모든데이터가 각 지사별로 분리되어 있는 형태를 가지고 있다.

- 칼럼을 기준으로 분할 하였기 때문에 각각의 테이블에는 동일한 Primary key 구조와 값을 가지고 있어야한다.

- 통합하여 처리해야하는 프로세스가 많을 경우 이용하지않는다.

다. 테이블 복제 분산

- 테이블 복제 분산은 동일한 테이블을 다른 지역이나 서버에 동시에 생성하여 관리하는 유형이다.

- 마스터데이터베이스에서 테이블의 일부의 내용만 다른 지역이나 서버에 위치시키는 부분복제가 있고, 마스터 데이터베이스의 내용을 각 지역이나 서버에 존재시키는 광역복제가 있다.

1) 부분복제

- 통합된 테이블을 한군데에 가지고 있으면서 각 지사별로는 지사에 해당된 로우를 가지고 있는 형태이다.

- 지사에 존재하는 데이터는 반드시 본사에 존재하게된다.

- 지사에서 데이터 처리가 용이할 뿐만 아니라 전체 테이터에 대한 통합처리도 본사에 있는 통합테이블을 이용하게 되므로 조인이 발생하지 않는 빠른 작업수행이 가능하다.

- 지사간에는 데이터 중복이 발생되지 않으나, 지사와 본사 간에는 데이터 중복이 항상 발생하게된다.

- 야간에 배치작업에 의해 데이터 복제를 한다.

- 본사와 지사 양쪽 모두 데이터를 수정하여 전송하는 경우 데이터 정합성을 일치시키는게 어렵기 때문에 가능하면 지사에서 데이터 수정이 발생하여 본사로 복제하도록 한다.

2) 광역복제

- 통합된 테이블을 본사에서 가지고 있으면서 각 지사에도 본사와 동일한 데이터를 모두 가지고 있는 형태이다.

- 지사에 존재하는 데이터는 반드시 본사에 존재하게 된다.

- 모든 지사의 데이터양과 본사에 있는 데이터 양은 동일하다.

- 부분복제의 경우 지사에서 데이터에 대한 입력,수정,삭제가 발생하여 본사에 이용하는 방식이 많은 반면에 광역복제의 경우에는 본사에서 데이터가 입력 수정 삭제가 발생되어 지사에서 이용하는 형태가 많다.

- 데이터를 복제하는데 많은 시간이 소요되므로 배치에 의해 복제되도록 한다.

라. 테이블 요약 분산

- 테이블 요약 분산은 지역간에 또는 서버간에 데이터가 비슷하지만 서로 다른 유형으로 존재하는 경우가 있다.

요약 방식에 따라 동일한 테이블 구조를 가지고 있으면서 분산되어 있는 동일한 내용의 데이터를 이용하여 통합된 데이터를 산출하는 방식의 분산석요약과 분산되어 있는 다른 내용의 데이터를 이용하여 통합된 데이터를 산출하는 방식의 통합요약이 있다.

1) 분석요약

- 각 지사별로 존재하는 요약정보를 본사에 통합하여 다시 전체에 대해서 요약정보를 산출하는 분산방법이다.

- 통합 통계데이터에 대한 정보제공에 용이한 분산방법이다.

2)통합요약

- 각 지사별로 존재하는 다른 내용의 정보를 본사에 통합하여 다시 전체에 대해서 요약정보를 산출하는 분산방법이다.

- 통합요약은 단지 지사에서 산출한 요약정보를 한군데 취합하여 보여주는 형태이다. 분석요약은 지사에 있는 데이터를 이용하여 본사에서 통합하여 요약데이터를 산정하지만 통합요약에서는 자사에서 요약한 정보를 취합하여 각 지사별로 데이터를 비교하기위해 있는것이다.

* 각종 통계데이터를 산정할 경우에 모든 지사의 데이터를 조인하여 처리하면 성능이 저하되고 각 지사 서버에 부하를 주기 때문에 장애가 발생할 수 있다.  본사에 통합 요약된 테이블을 생성하고 데이터는 야간에 수행하여 생성하는것이 일반적인 적용방법이다.

7. 분산 데이터베이스를 적용하여 성능이 향상된 사례

- 복제분산의 원리를 이용하면 성능을 향상시켜 설계할 수 있다.

- 트랜잭션 개별적으로 원격지 조인 -> 트랜잭션 내부조인(배치이동)

*분산데이터베이스 설계는 다음경우에 이용하면 효과적이다.

1) 성능이 중요한 사이트에 적용.

2) 공통코드, 기준정보, 마스터데이터 등에 대해 분산환경을 구성하면 성능이 좋아진다.

3) 실시간 동기화가 요구되지 않을 때 좋다.

4) 특정 서버에 부하가 집중될 때 부하를 분산할 때도 좋다.

5) 백업 사이트를 구성할 때 간단하게 분산기능을 적용하여 구성할 수 있다.

[SQLD] 1과목 데이터 모델링의 이해 - 2장 5절:데이터베이스 구조와 성능

1. 슈퍼타입/ 서브타입 모델의 성능고려 방법.

가. 슈퍼/서브타입 데이터 모델의 개요.

- Extended ER모델이라고 부르는 슈파타입/서브타입 데이터 모델은 최근에 데이터 모델링을 할 때 자주 쓰이는 모델링 방법이다.

- 업무를 구성하는 데이터의 특징을 공통점과 차이점의 특징을 고려하여 효과적으로 표현할 수 있기 때문.

- 공통의 부분을 슈퍼타입으로 모델링하고 공통으로부터 상속받아 다른 엔터티와 차이가 있는 속성에 대해서는 별도의 서브엔터티로 구분하여 업무의 모습을 정확하게 표현하면서 물리적인 데이터 모델로 변환을 할 때 선택의 폭을 넓힐 수 있는 장점이 있다.

- 슈퍼/서브타입의 데이터 모델은 논리적 데이터 모델에서 이용되는 형태이며 분석/설계단계를 구분하자면 분석단계에서 많이 쓰이는 모델이다.

- 물리적인 데이터모델을 설계하는 단계에서는 슈퍼/서브타입 데이터 모델을 일정한 기준에 의해 변환해야한다.

- 물리적인 데이터모델이 성능을 고려한 데이터 모델이 되어야한다는 점을 고려하면 이렇게 막연하게 슈퍼/서브타입을 아무런 기준없이 변환하는것 자체가 성능이 저하될 수 있음을 기억해야한다.

나. 슈퍼/서브타입 데이터 모델의 변환

- 슈퍼 서브타입에 대한 변환을 잘못하여 성능이 저하되는 경우.

1) 트랜잭션은 항상 일괄로 처리하는데 테이블은 개별로 유지되어 UNION 연산에 의해 성능이 저하될 수 있다.

2) 트랜잭션은 항상 서브타입 개별로 처리하는데 테이블은 하나로 통합되어 있어 불필요하게 많은 양의 데이터가 집약되어 있어 성능이 저하되는 경우가 있다.

3) 트랜잭션은 항상 슈퍼+서브타입을 공통으로 처리하는데 개별로 유지되어 있거나 하나의 테이블로 집약되어 있어 성능이 저하되는 경우가 있다.

* 해당 테이블에 발생되는 성능이 중요한 트랜잭션이 빈번하게 처리되는 기준에 따라 테이블을 설계해야 성능저하 현상을 예방할 수 있다.

* 슈퍼/서브타입을 성능을 고려한 물리적인 데이터 모델로 변환하는 기준은 데이터 양과 해당 테이블에 발생되는 트랜잭션의 유형에 따라 결정된다.

* 데이터의 양은 소량일 경우 데이터 처리의 유연성을 고려하여 가급적 1:1관계를 유지하는것이 바랍직하다.

* 데이터의 양이 많을 경우 그리고 해당 업무적인 특징이 성능에 민감한 경우에는 트랜잭션이 해당 테이블에 어떻게 발생되는지에 따라 3가지 변환방법을 참조하여 변환해야한다.

다. 슈퍼/서브 타입 데이터 모델의 변환 기술.

- 논리적인 데이터 모델에서 설계한 슈퍼타입/서브타입 모델을 물리적인 데이터 모델로 전환할 때 주로 어떤 유형의 트랜잭션이 발생하는지 검증해야한다.

- 데이터양이 많이 존재하고 지속적으로 증가하는 양도 많다면 슈퍼타입/서브타입에 대해 물리적인 데이터모델로 변환하는 세 가지 유형에 대해 세심하게 적용해야한다.

1) 개별로 발생하는 트랜잭션에 대해서는 개별 테이블로 구성.

- 슈퍼타입과 서브타입 각각에 대해 독립적으로 트랜잭션이 발생이 되면 슈퍼타입에도 꼭 필요한 속성만 가지게 하고 서브타입에도 꼭 필요한 속성만 가지게 하기 위해서 모두 분리하여 1:1 관계를 갖도록 한다.

- 실전프로젝트에서는 데이터양이 대용량으로 존재하는 경우에 공통으로 이용하는 슈퍼타입의 속성의 수가 너무 많아져 디스크 I/O가 많아지는 것을 방지하기 위해 각각을 1:1 관계로 가져가는 경우도 있다.

2) 슈퍼타입+ 서브타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼타입+서브타입 테이블로 구성

-  만약 대리인이 10만건 매수인 500만건 이해관계인 500만건의 데이터가 존재할 때, 슈퍼타입과 서브타입이 모두 하나의 테이블로 구성되어있을 경우 매수인 이해관계인에 대한 정보는 배제하고 10만건인 대리엔이데핸 데이터만 처리할 경우 다른테이블과 같이 1010만건 데이터가 저장되어있는 곳에서 처리하므로 불필요한 성능저하가 발생하게된다.

=>  이처럼 슈퍼타입과 서브타입을 묶어 트랜잭션이 발생하는 업무특징을 가지고 있을 때에는 슈퍼타입+서브타입을 각각 하나로 묶어 별도의 테이블로 구성하는것이 효율적이다.

3) 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성.

- 대리인이 10만건, 매수인이 500만건, 이해관계인 500만건의 데이터가 존재한다고 하더라도 데이터를 처리할 때 대리인, 매수인, 이해관계인을 항상 통합하여 처리한다고 하면 테이블을 개별로 분리하면  불필요한 조인을 유발하거나 불필요한 UNION ALL과 같은 SQL 구문이 작성되어 성능이 저하된다. 비록 슈퍼타입과 서브타입의 테이블을 하나로 묶었을 때 각각의 속성별로 제약사항을 정확하기 지정하지 못할 지라도 대용량이고 성능향상에 필요하다면 하나의 테이블로 묶어서 만들어준다.

라. 슈퍼/서브타입 데이터 모델의 변환타입 비교.

2. 인덱스 특성을 고려한 PK/FK 데이터베이스 향상.

가. PK/FK 칼럼순서와 성능개요.

- 데이터를 조회할 때 가장 효과적으로 처리될 수 있도록 접근경로를 제공하는 오브젝트가 인덱스이다.

- 일반적으로 데이터베이스 테이블에서는 균형잡힌 B*Tree 구조를 많이 사용한다.

- 테이블에 발생되는 트랜잭션의 조회패턴에 따라 PK/FK 칼럼의 순서를 조정해야한다.

- PK는 해당 테이블의 데이터에 접근할 때 가장 빈번하게 사용되는 유일한 인덱스를 모두 자동생성한다.

- PK 순서를 결정하는 기준은 인덱스 정렬구조를 이해한 상태에서 인덱스를 효율적으로 이용할 수 있도록 PK순서를 지정해야한다.

* 여러개의 속성이 하나의 인덱스로 구성되어 있을 때 앞쪽에 위치한 속성의 값이 비교자로 있어야 인덱스가 좋은 효율을 낼 수 있다.

* 앞쪽에 위치한 속성값이 가급적 '=' 아니면 최소한 범위 BEETWEEN, < > 가 들어와야 인덱스를 이용할 수 있다.

* 데이터 모델링 때 결정한 PK 순서와는 다르게 DDL 문장을 통해 PK 순서를 다르게 생성할 수 있다.

(하지만 보통 데이터 모델의 PK 순서에 따라 그대로 PK를 생성한다.)

* FK라고 하더라도 데이터를 조회할 때 조인의 경로를 제공하는 역할을 수행하므로 FK에 대해서는 반드시 인덱스를 생성하도록 하며 인덱스 칼럼의 순서도 조회의 조건을 고려하여 접근이 가장 효율적인 칼럼 순서대로 인덱스를 생성하도록 주의한다.

나. PK칼럼의 순서를 조정하지 않으면 성능이 저하되는 이유.

- 먼저 데이터 모델링에서 엔터티를 설계하면 그에 때라 DDL이 생성이 되고 생성된 DDL에 따라 인덱스가 생성된다.

- PK순서에 따라 DDL이 그대로 생성되고, 테이블의 주문번호가 가장먼저 정렬되고, 주문일자가 정렬되고 주문번호코드가 정렬이된다.

 1) 맨앞에 있는 인덱스 칼럼에 조회조건이 들어올 경우

SELECT 주문단가

FROM 주문목록

WHERE 주문번호 = '1002';

=> 인덱스에 정렬된 첫 번째 칼럼에 비교가 되었기 때문에 순차적으로 데이터를 찾아가게 된다.

2) 맨 앞에 있는 칼럼이 제외된 상태에서 데이터를 조회할 경우 데이터 비교버무이가 넓어지게되어 성능저하를 유발한다.

SELECT 주문단가

FROM 주문목록

WHERE 주문일자='2015.08.23';

=> 주문번호에 대한 비교값이 들어오지 않으므로 인덱스 전체를 다 읽은 후 원하는 데이터를 찾게된다. 이러한 이유로 인덱스를 읽고 데이터 블록에서 읽어 처리하는데 IO가 많이 발생하므로 옵티마이저는 차라리 테이블 전체를 읽는 방식으로 처리한다.

* PK의 순서를 인덱스 특징에 맞게 고려하지 않게 생성하게되면 테이블에 접근하는 트랜잭션의 특징에 효율적이지 않은 인덱스가 생성되어 있으므로 인덱스의 범위를 넓게 이용하거나 FULL SCAN을 유발하게 되어 성능이 저하된다고 할 수 있다.

다. PK순서를 잘못 지정하여 성능이 저하된 경우. - 간단한 오류

- 입시마스터라는 테이블의 PK는 수험번호+년도+학기로 구성되어 있고 전형과목실적 테이블은 입시마스터의 테이블에서 상속받은 수험번호+년도+학기에 전형과목코드로 PK가 구성되어있는 복합식별자 구조의 테이블이다.

- 입시마스터에는 200만 건의 데이터가 들어가있고 학사는 4학기로 구성되어 있고 데이터는 5년간 보관되어 한학기당 평균 2만 건의 데이터가 있을 때.

- 성능저하쿼리

=> 이 경우 입시마스터_I01인덱스가 수험번호+년도+학기 중 수험번호에 해당하는 값이 WHERE절에 들어오지 않으므로 FULL TABLE SCAN이 발생하게된다.

 * 입시마스터 테이블 조회시 년도와 학기가 빈번하게 들어오므로 PK순서를 변경함으로써 인덱스를 사용할 수 있도록 할 수 있다.

- PK 순서 변경 

라. PK순서를 잘못 지정하여 성능이 저하된 경우 - 복잡한 오류.

- 현금출급기의 PK는 거래일자+사무소코드+출급기번호+명세표번호로 되어있는데, 대부분 SQL 문장에서 조회를 할 때 사무소코드가 '='로 들어오고 거래일자에 대해서는 BETWEEN 조회를 하고있다.

이 때 SQL은 정상적으로 인덱스를 사용할 수 있지만 인덱스 효율이 떨어져 성능이 저하되는 경우에 해당한다.

=> 거래일자 + 사무소코드로 구성된 인덱스 이기 때문에 거래일자 범위때문에 조회범위가 넓어져서 성능저하가 발생한다.

 인덱스 구성을 사무소코드 + 거래일자로 구성하면 '='비교를 사용하므로써 범위가 좁혀질 수 있다.

* A+B 형식의 조회와 B+A 형식의 조회도 빈번하게 일어날 경우에는 좀 더 자주 이용되는 조회형태로 PK를 구성하고 순서를 바꾼 인덱스를 추가로 생성하는것이 좋다.

3. 물리적인 테이블에 FK제약이 걸려있지 않을 경우 인덱스 미생성으로 성능저하.

- 물리적인 테이블에 FK를 사용하지 않아도 데이터 모델 관계에 의해 상속받은 FK 속성들은 SQL WHERE절에서 조인이 이용되는 경우가 많이 있으므로 FK 인덱스를 생성해야 성능이 좋은 경우가 빈번하다.

- 학사기준과 수강신청에 대한 데이터모델에서 물리적인 테이블에는 두 테이블 사이에 FK 참조무결성 관계가 걸려있지 않을 때 학사기준 데이터에는 5만건의 데이터가있고 수강신청에 데이터가 500만건이 있다고 가정하면.

=> FK 인덱스 미생성으로 FULL TABLE스캔이 발생하여 성능 저하가 생긴다.

- 학사기준번호가 SQL절에 비교자로 들어오지는 않지만 수강신청 테이블에서 상속받은 학사기준번호에 대해 인덱스를 생성하지 않으므로 인해 학사기준과 수강신청 테이블이 조인이 되면서 500만건의 수강신청 테이블이 FULL SCAN이 발생하며 성능이 저하되었다.

- 이때는 수강신청 테이블에 FK인덱스를 생성하여 성능을 개선할 수 있다.

CREATE INDEX 수강신청_FK01 ON 수강신청(학사기준번호)

* 물리적으로 학사기준과 수강신청이 연결되어 있지 않다고 하더라도 학사기준으로부터 상속받은 FK에 대해 FK인덱스를 생성함으로써 SQL문장이 조인이 발생할 때 성능저하를 예방할 수 있다.

* 물리적인 테이블에 FK제약을 걸었을 때는 반드시 FK 인덱스를 생성하도록 하고 FK 제약이 걸리지 않았을 경우에는 FK인덱스를 생성하는것을 기본 정책으로 하되 발생되는 트랜잭션에 의해 거의 활용되지 않았을 때에만 FK 인덱스를 지우는 방법으로 하는것이 적절한 방법이다.