onCreate시에 아래 내용을 추가한다. 

requestWindowFeature(Window.FEATURE_NO_TITLE);

추가시에 setContentView 추가 전에 호출해야 한다. 

        requestWindowFeature(Window.FEATURE_NO_TITLE);
        setContentView(R.layout.main);

동일한 컬럼일 경우는 OR 조건이 유리

컬럼이 다를 경우에는 인덱스 여부를 판단하여 OR와 UNION을 선택

예) A=3 OR B=4 라고 하면

위의 조건은 아래와 같은 두 개의 쿼리로 분리할 수 있다. 

(1) A=3  조회   

(2) B=4 and A!='3' 

A와 B에 인덱스가 없다면 위의 조건으로 Table Full Scan이 발생할 가능성이 높다. 

이럴 경우 A와 B에 인덱스가 있다면 UNION 또는 UNION ALL을 사용하면 TABLE FULL SCAN을 줄일 수 있어 더 효과적이다. 

OR 연산을 UNION-ALL 연산을 사용하도록 변경하려면 

USE_CONCAT 힌트를 사용한다. 

UNION 은 중복을 제거하기 때문에 SORT를 사용한다. 

중복이 상관없다면 UNION ALL을 사용한다. 

메인 쿼리와 서브쿼리의 조합으로 구성되는 공통점 존재

IN은 서브 쿼리의 처리 범위가 적을 경우 효율적(서브 쿼리의 결과가 몇 개 안나올 때)

EXISTS는 메인 쿼리의 처리 범위가 적을 경우  효율적

가) 작업량을 줄이는 방법

 - 인덱스 또는 힌트를 사용하여 조회 대상의 범위를 축소 시키는 방법

나) 작업량의 균형을 맞추는 방법

- 사용자가 많은 시간에 DB 사용량이 많아 지므로, 잘 사용하지 않는 시간대에 일괄 처리 작업   

   등을 수행시켜 작업량의 균형을 맞추는 방법

다) 작업량의 병렬 처리

 - 대용량의 데이터를 병렬로 처리시키는 것

가. 실행계획 재검토

 - 초기 조회 조건의 범위를 최소한 줄일 수 있는 방법인지 검토한다. 

     (적절한 조인 방법, 인덱스를 사용, Table Full Scan 여부 등을 검토)

나. SQL 문장 재구성

1) WHERE 컬럼의 함수 사용 방지

2) 서브쿼리에서의 EXISTS, IN을 구분하여 사용

3) 힌트를 사용하여 접근 경로와 조인순서 제어

4) 인덱스들의 재구성

 - 사용하지 인덱스를 제거시, DML의 속도가 향상

5) 복합 인덱스의 컬럼 순서 재배열

 - 자주 사용하는 인덱스 순서대로 분포도를 확인하여 재배열

6) CASE문 활용

 - 공통으로 존재하는 컬럼을 조건에 따라 여러 개 조회하는 쿼리는 CASE문을 활용 

가. Nested Loop 조인과 Hash 조인의 차이점

 아래 내용 참조. 

 http://androiddev.tistory.com/admin/entry/post/?id=88

나. 조인 순서의 중요성

오라클 CBO는 힌트를 부여하지 않아도 레코드 수가 가장 적은 테이블부터 조인하도록 실행계획을 세운다. 

가. 인덱스를 활용한 부분범위 처리

     ORDER BY는 조건을 조회 후 다시 소팅을 한다. 

     ORDER BY 쿼리를 index_desc 힌트를 사용하면 Sorting 작업을 안하기 때문에 더 

 효율적 

나. MAX처리 

MAX는 조회 대상을 검색후 최대값을 구한다. 

MAX를 index_desc힌트와 rownum=1을 이용하면 인덱스에서 검색을 하기 때문에 더 효율적

다. EXISTS의 활용

EXISTS를 사용하면 원하는 데이터가 존재시에 즉시 탐색을 멈추도록 하기 때문에 IN을 사용하는 것보다 효율적일 수 있다.  

사용 기준)

주로 온라인 어플리케이션에서 사용.

부분범위 처리나 사용자가 데이터를 요구 했을 때 짧은 시간에 결과를 볼 수 있는 적은 데이터를 액세스 할 때 사용.

원리) 

양쪽 테이블을 각자 액세스하여 처리 범위를 줄이고, 조인컬럼 순으로 데이터를 Sort한  후에 조인컬럼으로 조인한다. 

각 테이블에 주어진 조건으로 처리 범위를 줄인 후 Sort하고, 각 테이블을 조인한다. 

조인 시에 인덱스를 사용하지 않는다. 

사용 기준)

각 테이블이 범위를 많이 줄일 수 있을 때

조인 컬럼의 인덱스가 필요 없을 때

두 테이블의 데이터의 양이 비슷할 때

단점)

두 테이블의 크기가 많이 차이 나는 경우에는 비효율적이다. (각 테이블의 정렬 작업이 종료되지 않으면 조인이 시작될 수 없어 그 만큼 지연 시간이 발생한다.)

배경) 

대용량 처리의 선결조건인 랜덤 I/O와 정렬에 대한 부담을 해결할 수 있는 대안으로 등장. 

특징)

인덱스를 사용하지 않는다. 

CPU, 메모리의 성능에 의존적이다. 

해쉬코드를 사용하기 때문에 '='로 수행하는 동등 조건에서만 사용 가능 

메모리에 해쉬 테이블을 생성하기 때문에 작은 테이블이 존재해야 한다. 

사용 기준) 

조인되는 컬럼이 인덱스가 없을 경우.(어차피 Full Scan을 해야한다.)

대량의 데이터 엑세스 시(배치 처리) 

Full Table Scan 하면서 조인 해야 할 때 유리하다. 

비용은 많이 들지만 수행속도를 보장해야 하는 작업에 유용하다.