테이블을 파티셔닝하여 운영하실 경우 파티션 키를 포함하지 않는 조건의 SQL 에 대하여 성능저하가 발생할 수 있다는 점을 고려하셔야 하겠습니다.

(물론 당연히 파티션을 구성하여 성능이 개선되는 케이스가 많음-파티션키에대한 조건이 포함될 경우)

영구 보관 성격의 테이블이 아니라면 보관주기를 가지고 보관주기 이전 데이터를 담고있는 파티션에 대한 DROP 작업도 함께 검토해보시면 좋겠습니다

어플리케이션이 최근 데이터면 사용한다면, 과거 데이터는 삭제 또는 보관하시면서 최근 데이터만 유지하는 식으로 관리하는 것이 좋아 보입니다. 이력성으로 쌓기만 하고 조회나 변경은 별로 없는 테이블이라면 월별로 만드는 것도 괜찮을 듯 합니다. 

//임상준

조회조건에 파티션 키가 없으면 파티션 태이블 전체를 전부 읽음 파티션이 많이 쳐져있을수록 느려짐

1. 파티션 테이블은 조건에 파티션키가 있어야한다

2. 파티션키로 안되면 글러발 비파티션 인덱스를 만든다 ( 성능고도화책에 나옴)

저희도 계속 누적되어 쌓이는 자료(입금 데이터)를 어떻게 할까 고민중이네요. 

죄송합니다. 제가 내용을 빠트렸네요.
데이터는 영구보관해야 하며
주기적으로 통계 데이터를 만들어서 사용 하고 있고
최근 데이터를 주로 조회 하고 있는 상황입니다.

DBA 업무 2년차지만, 개인적인 의견 드립니다.
- 테이블 3개로 관리
1. 현 운영테이블
  - 업무상 필요한 최근 데이터만 보관

2. 이력 테이블
 - 운영 테이블과 구조가 같은 파티션 테이블의 연월 컬럼 추가하여 생성
 - 최근 데이터를 제외한 과거 데이터 보관
 - 월 또는 분기에 파티션 작업 필요
 - ETL 또는 배치로 이관

3. 통계 테이블
 - 목적을 모르나 데이터를 집계할 경우 별도 파티션 테이블 생성
 - ETL 또는 배치로 집계하여 데이터 이관
 - 단 실시간은 아님