本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 在分割資料表中封存資料
<a name="archive-partitioned-tables"></a>

MySQL 支援 InnoDB 儲存引擎的[分割](https://dev.mysql.com/doc/refman/8.0/en/partitioning.html)，您可以使用此功能來分割大型資料表。資料表中的分割區會儲存為個別的實體資料表，不過在分割資料表上操作的 SQL 會讀取整個資料表。這可讓您自由地從資料表中移除不需要的分割區，而無需執行row-by-row刪除，因此您可以在資料庫中封存歷史資料列。

請考慮下列範例程式碼。 `orderprocessing` `TABLE orders`存在於結構描述中。其歷史資料存在於分割區 `phistorica`l 中，其中包含屬於 2021 年及更早版本的資料。在同一資料表中，應用程式層級的熱資料存在於 2022 年每個月的即時分割區中。若要在分割區 中封存資料`phistorical`，您可以在`archive`結構描述中`table orders_2021_and_older`建立具有相同結構的封存。然後，您可以使用 MySQL [EXCHANGE PARTITION](https://dev.mysql.com/doc/refman/8.0/en/partitioning-management-exchange.html) 將分割區移至`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 時，這非常有用。
+ 當 Aurora MySQL 相容寫入器、Amazon RDS for MySQL 或 Amazon RDS for MariaDB 執行個體沒有流量進入時，請在停機時間視窗中執行`EXCHANGE PARTITION`資料定義語言 (DDL) 陳述式。

  您可以在應用程式或微服務中的低流量時段`EXCHANGE PARTITION`執行 。不過，分割的資料表上應該沒有寫入，也沒有或很少選取。現有的長時間執行選取查詢可能會導致 `EXCHANGE PARTITION` DDL 等待，導致資料庫出現資源爭用。在`EXCHANGE PARTITION`系統上執行 之前，驗證符合所有這些條件的設計指令碼。

如果您的應用程式設計可以支援分割的資料，而且您目前有未分割的資料表，請考慮將資料移至分割的資料表，以支援封存資料。如需詳細資訊，請參閱 [MySQL 文件](https://dev.mysql.com/doc/refman/8.0/en/alter-table-partition-operations.html)。