기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
파티션을 나눈 테이블에 데이터 보관
MySQL 지원분할
다음 예제 코드를 살펴보십시오.TABLE orders내에 존재합니다orderprocessing스키마. 과거 데이터가 파티션에 있습니다.phistorical, 2021 및 이전 버전의 데이터를 포함합니다. 같은 표에서 애플리케이션 수준의 핫 데이터는 2022년 매월 라이브 파티션에 있습니다. 파티션에 데이터를 보관하려면phistorical, 아카이브를 만들 수 있습니다.table orders_2021_and_older동일한 구조로archive스키마. 그런 다음 MySQL을 사용할 수 있습니다.익스체인지 파티션phistorical저 테이블로. 참고로 아카이브 테이블은 파티셔닝되지 않습니다. 보관 후에는 데이터를 확인하고 Amazon S3로 이동할 수 있습니다.
CREATE TABLE orders ( orderid bigint NOT NULL AUTO_INCREMENT, customerid bigint DEFAULT NULL, ............ ............ order_date date NOT NULL, PRIMARY KEY (`orderid`,`order_date`)) PARTITION BY RANGE (TO_DAYS(order_date)) ( PARTITION pstart VALUES LESS THAN (0), PARTITION phistorical VALUES LESS THAN (TO_DAYS('2022-01-01')), PARTITION p2022JAN VALUES LESS THAN (TO_DAYS('2022-02-01')), PARTITION p2022FEB VALUES LESS THAN (TO_DAYS('2022-03-01')), PARTITION p2022MAR VALUES LESS THAN (TO_DAYS('2022-04-01')), PARTITION p2022APR VALUES LESS THAN (TO_DAYS('2022-05-01')), PARTITION p2022MAY VALUES LESS THAN (TO_DAYS('2022-06-01')), PARTITION p2022JUN VALUES LESS THAN (TO_DAYS('2022-07-01')), PARTITION p2022JUL VALUES LESS THAN (TO_DAYS('2022-08-01')), PARTITION p2022AUG VALUES LESS THAN (TO_DAYS('2022-09-01')), PARTITION p2022SEP VALUES LESS THAN (TO_DAYS('2022-10-01')), PARTITION p2022OCT VALUES LESS THAN (TO_DAYS('2022-11-01')), PARTITION p2022NOV VALUES LESS THAN (TO_DAYS('2022-12-01')), PARTITION p2022DEC VALUES LESS THAN (TO_DAYS('2023-01-01')), PARTITION pfuture VALUES LESS THAN MAXVALUE ); CREATE TABLE orders_2021_and_older ( orderid bigint NOT NULL AUTO_INCREMENT, customerid bigint DEFAULT NULL, ............ ............ order_date date NOT NULL, PRIMARY KEY (`orderid`,`order_date`)); mysql> alter table orderprocessing.orders exchange partition phistorical with table archive.orders_2021_and_older; Query OK, 0 rows affected (0.33 sec)
사용할 때EXCHANGE PARTITION기록 데이터를 보관하는 기능을 사용하려면 다음과 같은 모범 사례를 사용하는 것이 좋습니다.
-
애플리케이션에 아카이브 데이터를 저장하기 위한 별도의 스키마를 생성합니다. 이 스키마에는 보관된 데이터를 보관할 아카이브 테이블이 포함됩니다. 아카이브 스키마의 아카이브 테이블은 인덱스 및 기본 키를 포함하여 라이브 테이블과 구조가 동일해야 합니다. 그러나 대상 아카이브 테이블은 분할된 테이블일 수 없습니다. MySQL에서는 분할된 두 테이블 간의 파티션 교환이 허용되지 않습니다.
-
보관 테이블에 저장된 기간별 데이터를 식별하는 데 도움이 되는 명명 규칙을 따르십시오. 이는 감사 작업을 수행하거나 이 데이터를 Amazon S3로 이동하는 설계 작업을 수행할 때 유용합니다.
-
다음을 수행하십시오.
EXCHANGE PARTITIONAurora MySQL 호환 라이터, MySQL용 Amazon RDS 또는 MariaDB용 Amazon RDS 인스턴스로 들어오는 트래픽이 없을 때 다운타임 기간에 나타나는 데이터 정의 언어 (DDL) 명령문.실행할 수 있을 수도 있습니다.
EXCHANGE PARTITION애플리케이션 또는 마이크로서비스의 트래픽이 적은 시간대에 그러나 파티셔닝된 테이블에는 쓰기가 없어야 하며 선택 항목이 없거나 거의 없어야 합니다. 오래 실행되는 기존 선택 쿼리는 다음과 같은 원인이 될 수 있습니다.EXCHANGE PARTITIONDDL이 대기하여 데이터베이스에서 리소스 경합이 발생합니다. 실행 전에 이러한 모든 조건이 충족되는지 확인하는 스크립트를 설계하십시오.EXCHANGE PARTITION시스템에.
애플리케이션 디자인이 분할된 데이터를 지원할 수 있고 현재 분할되지 않은 테이블이 있는 경우 데이터 보관을 지원하기 위해 데이터를 분할된 테이블로 이동하는 것을 고려해 보십시오. 자세한 내용은 MySQL 설명서
