封存分區資料表中的資料 - AWS 規範指南

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

封存分區資料表中的資料

支持分區對於 InnoDB 存儲引擎，您可以使用此功能對大表進行分區。雖然在資料分割資料表上運作的 SQL 會讀取整個資料表，但資料表中的資料分割會儲存為個別的實體資料表。這使您可以自由地從表中刪除不需要的分區，而無需執行row-by-row刪除，以便您可以在數據庫中存檔歷史行。

請考慮下面的示例代碼。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 PARTITION當沒有流量進入您的 Aurora MySQL 相容寫入器、適用於 MySQL 的 Amazon RDS 或適用於 MariaDB 執行個體的 Amazon RDS 時，停機時間視窗中的資料定義語言 (DDL) 陳述式。

    它可能是可以運行EXCHANGE PARTITION在應用程式或微服務中的低流量視窗期間。但是，應該沒有寫入，也不應該在分區表上選擇或很少選擇。現有的長時間運行選擇查詢可能會導致EXCHANGE PARTITIONDDL 等待，導致資料庫上的資源爭用。運行之前驗證所有這些條件都符合的設計腳本EXCHANGE PARTITION在您的系統上。

如果您的應用程式設計可以支援分區資料，而您目前有未分割的資料表，請考慮將資料移至分區資料表，以支援將資料歸檔。如需詳細資訊，請參閱 MySQL 文件。