Amazon 的最佳實踐 RDS

了解與 Amazon 合作的最佳實務RDS。在新最佳實務確定時，我們會不斷更新此小節。

注意

如需 Amazon 的常見建議RDS，請參閱 的建議 RDS。

Amazon RDS 基本操作指南

以下是每個人在使用 Amazon 時都應遵循的基本操作準則RDS。請注意，Amazon RDS 服務級別協議要求您遵循以下準則：

• 使用指標來監視您的記憶體CPU、複本延遲和儲存空間使用量。您可以設定 Amazon CloudWatch 在使用模式變更或部署接近容量限制時通知您。這可讓您維持系統效能和可用性。

• 在您處理儲存容量限制時向上擴展資料庫執行個體。您應該在儲存體和記憶體中具有一些緩衝，以容納應用程式需求中未知的增加。

• 啟用自動備份，並將備份視窗設定為在每日低寫入時發生IOPS。此時備份對資料庫使用情況產生的干擾最少。

• 如果資料庫工作負載所需的 I/O 較您佈建得多，容錯移轉或資料庫失敗之後的復原將會很緩慢。若要增加資料庫執行個體的 I/O 容量，請執行下列任何或所有動作：

  • 遷移至具有高 I/O 容量的其他資料庫執行個體類別。

  • 根據您需要的增加量，從磁帶IOPS儲存轉換為一般用途或佈建儲存體。如需可用儲存體類型的詳細資訊，請參閱Amazon RDS儲存體類型。

    如果您轉換為佈建IOPS儲存，請確定您也使用針對佈建最佳化的資料庫執行個體類別IOPS。如需有關已佈建的資訊IOPS，請參閱佈建的IOPSSSD儲存體。

  • 如果您已在使用佈建的IOPS儲存體，請佈建額外的輸送量容量。

• 如果您的用戶端應用程式快取資料庫執行個體的網域名稱服務 time-to-live (DNSTTL) 資料，請設定小於 30 秒的 () 值。資料庫執行個體的基礎 IP 位址可能會在容錯移轉後變更。長時間快取DNS資料可能會導致連線失敗。您的應用程式可能會嘗試連線到不再提供服務的 IP 地址。

• 測試資料庫執行個體的容錯移轉，以了解您的特定使用案例執行此程序需時多長。也會測試容錯移轉，以確保可存取您資料庫執行個體的應用程式，可以在容錯移轉發生之後，自動連線到新的資料庫執行個體。

資料庫執行個RAM體

Amazon RDS 效能最佳實務是配置足夠的工作集，RAM讓您的工作集幾乎完全存放在記憶體中。工作集是您的執行個體經常使用的資料和索引。您越常使用資料庫執行個體，工作集會成長越多。

若要判斷您的工作集是否幾乎都在記憶體中，請在資料庫執行個體負載時檢查讀取IOPS指標 (使用 Amazon CloudWatch)。讀取的值IOPS應該很小且穩定。在某些情況下，將資料庫執行個體類別擴展為類別，RAM導致更多結果，在 Read 中大幅下降IOPS。在這些情況下，您的工作集幾乎完全不在記憶體中。繼續擴展，直到縮放操作後「讀取」IOPS 不再顯著下降，或者「讀取IOPS」減少到非常小的數量為止。如需監控資料庫執行個體之指標的詳細資訊，請參閱在 Amazon RDS 主控台中檢視指標。

AWS 資料庫驅動

我們推薦 AWS 應用程式連線的驅動程式套件。這些驅動程式的設計旨在提供更快的切換和容錯移轉時間以及驗證的支援 AWS Secrets Manager, AWS Identity and Access Management (IAM) 和聯合身分識別。所以此 AWS 驅動程式仰賴監控資料庫執行個體狀態，並瞭解執行個體拓撲來判斷新的寫入器。這種方法可將切換和容錯移轉時間縮短為個位數秒，而開放原始碼驅動程式則需要數十秒。

隨著新服務功能的推出，目標 AWS 驅動程序套件是為這些服務功能提供內置支持。

如需詳細資訊，請參閱使用 AWS 驅動程式連線至資料庫執行個體。

使用 Enhanced Monitoring 來識別作業系統問題

啟用增強型監控後，RDSAmazon 會即時為執行資料庫執行個體的作業系統 (OS) 提供指標。您可以使用主控台來檢視資料庫執行個體的指標。您也可以在您選擇的監控系統中使用 Amazon CloudWatch 日誌的增強型監控JSON輸出。如需增強型監控的詳細資訊，請參閱使用增強型監控來監控作業系統指標。

使用指標來識別效能問題

若要識別資源不足和其他常見瓶頸造成的效能問題，您可以監控 Amazon 資RDS料庫執行個體可用的指標。

檢視效能指標

您應該定期監控效能指標以查看各種時間範圍的平均值、最大值和最小值。如果這麼做，當效能降級時您便可以得知。您也可以為特定的測量結果閾值設定 Amazon CloudWatch 警示，以便在達到警示時收到警示。

為了對效能問題進行故障診斷，請務必了解系統的基礎效能。當您設定資料庫執行個體並使用一般工作負載執行它時，請擷取所有效能指標的平均值、最大值和最小值。以數個不同的間隔（例如，一小時、24 小時、一週、兩週）進行此操作。這可讓您了解正常運作情況為何。這有助於比較尖峰與離峰時段的操作。之後您可以使用此資訊來得知效能是否下降至標準層級之下。

如果使用多可用區域資料庫叢集，請監控寫入器資料庫執行個體上的最新交易與讀取器資料庫執行個體上最新套用交易之間的時間差異。這種差異被稱為複本延遲。如需詳細資訊，請參閱複本延遲和多可用區域資料庫叢集。

您可以在 Performance Insights 儀表板中檢視合併的 Performance Insights 和 CloudWatch 指標，並監視資料庫執行個體。若要使用此監控檢視，必須為您的資料庫執行個體開啟績效詳情。如需此監控檢視的相關資訊，請參閱 使用「Performance Insights」儀表板檢視合併指標。

您可以針對特定時間區間建立效能分析報告，並檢視所識別出的洞見和解決問題的建議。若要取得更多資訊，請參閱在績效洞察中建立效能分析報告。

檢視效能指標

1. 登入 AWS Management Console 並在打開 Amazon RDS 控制台https://console.aws.amazon.com/rds/。

2. 在導覽窗格中，選擇 Databases (資料庫)，然後選擇一個資料庫執行個體。

3. 選擇 Monitoring (監控)。

   儀表板提供效能指標。這些指標預設為顯示過去三小時的資訊。

4. 使用右上角的編號按鈕，來切換至其他指標頁面，或調整設定以查看更多指標。

5. 選擇用來調整時間範圍的效能指標，以查看當日以外的資料。您可以變更 Statistic (統計資料)、Time Range (時間範圍) 和 Period (期間) 值來調整顯示的資訊。例如，您可能想要查看某個指標過去兩週每天的尖峰值。若是如此，請將 Statistic (統計資料) 設定為 Maximum (最大值)、將 Time Range (時間範圍) 設定為 Last 2 Weeks (過去 2 週)、將 Period (期間) 設定為 Day (日)。

您也可以使用CLI或來檢視效能測量結果API。如需詳細資訊，請參閱在 Amazon RDS 主控台中檢視指標。

設定 CloudWatch 鬧鐘

1. 登入 AWS Management Console 並在打開 Amazon RDS 控制台https://console.aws.amazon.com/rds/。

2. 在導覽窗格中，選擇 Databases (資料庫)，然後選擇一個資料庫執行個體。

3. 選擇 Logs & events (日誌和事件)。

4. 在 [鬧CloudWatch 鐘] 區段中，選擇 [建立鬧鐘]。

   

5. 針對 [傳送通知]，選擇 [是]，並針對 [傳送通知至] 選擇 [新增電子郵件或SMS主題]。

6. 針對 Topic name (主題名稱)，輸入通知的名稱，並針對 With these recipients (含有以下收件人)，輸入以逗號分隔的電子郵件地址或電話號碼清單。

7. 針對 Metric (指標)，選擇警示數統計資料和指標來設定。

8. 針對 Threshold (臨界值)，指定指標是否必須大於、小於或等於閾值，並指定閾值。

9. 針對 Evaluation Period (評估期間)，選擇警示的評估期間。針對 consecutive period(s) of (連續期間)，選擇臨界值必須符合才能觸發警示的期間。

10. 針對 Name of alarm (警示名稱)，輸入警示的名稱。

11. 選擇Create Alarm (建立警示)。

鬧鐘會出現在CloudWatch 鬧鐘區段中。

評估效能指標

資料庫執行個體有一些不同類別的指標，而如何判斷可接受的值取決於指標。

CPU

• CPU[使用率] — 使用的電腦處理能力百分比。

記憶體

• 可用記憶體 — 資料庫執行個體上RAM有多少可用記憶體，以位元組為單位。監視索引標籤度量中的紅線標示為 75%CPU，記憶體和儲存指標。如果執行個體記憶體的耗用量經常超過該線，這表示您應該檢查工作負載或升級執行個體。

• 交換使用量 — 資料庫執行個體使用了多少交換空間，以位元組為單位。

磁碟空間

• 可用儲存空間 – 資料庫執行個體目前尚未使用的磁碟空間 (以 MB 為單位)。

輸入/輸出操作

• 讀取IOPS、寫入 IOPS — 每秒的平均磁碟讀取或寫入作業數。

• 讀取延遲、寫入延遲 – 讀取或寫入操作的平均時間 (以毫秒為單位)。

• 讀取傳輸量、寫入傳輸量 – 每秒自磁碟讀取或寫入至其中的平均數量 (以 MB 為單位)。

• 佇列深度 – 等候寫入至磁碟或從其中讀取的 I/O操作數量。

網路流量

• 網路接收輸送量、網路傳輸輸送量 – 每秒自資料庫執行個體來回傳送的網路流量速度 (以位元組為單位)。

資料庫連線

• 資料庫連線 – 連線至資料庫執行個體的用戶端工作階段數量。

如需可用效能指標的個別詳細說明，請參閱使用 Amazon 監控 RDS 指標 CloudWatch。

一般來說，效能指標的可接受值視您的基準為何，以及您的應用程式所做之事而定。調查距離基準的一致或趨勢變異。關於特定類型指標的建議如下所示：

• 高CPU或RAM消費- 高值CPU或RAM消費可能是合適的。例如，如果它們與應用程式的目標 (如輸送量或並行) 一致且是預期的，它們可能就是這樣。

• 磁碟空間消耗量 – 如果使用的空間持續保持在等於或高於總磁碟空間的 85%，請調查磁碟空間消耗量。看看從執行個體刪除資料或將資料封存至不同的系統來釋出空間是否可行。

• 網路流量 – 對於網路流量，請洽系統管理員，以了解您的網域網路和網際網路連線預期的輸送量。調查網路流量的傳輸量是否如預期一致地降低。

• 資料庫連線 – 如果您看到大量使用者連線，同時執行個體效能下降且回應時間延長，請考慮限制資料庫連線。資料庫執行個體使用者連線的最佳數量，將因執行個體類別和要執行的操作複雜性而不同。若要判定資料庫連線的數目，請將資料庫執行個體與參數群組建立關聯。在此群組中，將 User Connections (使用者連線) 參數設定為 0 (無限制) 以外的值。您可以使用現有的參數群組或建立新的參數群組。如需詳細資訊，請參閱 的參數組 RDS。

• IOPS指標 — 測量結IOPS果的預期值取決於磁碟規格和伺服器組態，因此請使用您的基準來瞭解典型值。調查值是否與您的基準一致地不同。為了獲得最佳IOPS效能，請確保您的典型工作集適合記憶體，以將讀取和寫入作業降到最低。

對於效能指標的問題，改善效能的第一步是調整最常用和最昂貴的查詢。調整它們，以查看這樣做是否會降低系統資源的壓力。如需詳細資訊，請參閱調校查詢。

如果您的查詢已調整並且問題仍然存在，請考慮升級您的 Amazon RDS 數據庫實例類。您可以將其升級為具有更多與問題相關的資源（CPURAM，磁盤空間，網絡帶寬，I/O 容量）的一個。

調校查詢

改善資料庫執行個體效能的一個最佳方式是調校最常使用與資源最密集的查詢。在這裡，您可以調整它們，讓它們的執行成本更便宜。如需有關改善查詢的資訊，請使用下列資源：

• 我的 SQL — 請參閱我的SQL文件中的最佳化SELECT陳述式。如需其他查詢調整資源，請參閱我的SQL效能調整和最佳化資源。

• Oracle — 請參閱 Oracle 資料庫說明文件中的資料庫SQL調整指南。

• SQL伺服器 — 請參閱 Microsoft 說明文件中的分析查詢。您也可以使用 Microsoft 文件中「系統動態管理檢視」中所述的執行、索引和 I/O 相關資料管理檢視 (DMVs) 來疑難排解SQL伺服器查詢問題。

  查詢調校的一般層面為建立有效的索引。如需資料庫執行個體的潛在索引改進，請參閱 Microsoft 文件中的 Database Engine Tuning Advisor。如需有關在SQL伺服器上使用調整建議程式RDS的資訊，請參閱使用 Database Engine Tuning Advisor 在 Amazon RDS for SQL Server 資料庫執行個體上分析資料庫工作負載。

• 下一步 SQL — 請參閱 Postgre SQL 文件EXPLAIN中的使用，以瞭解如何分析查詢計畫。您可以使用此資訊來修改查詢或基礎資料表以改善查詢效能。

  如需如何在查詢中指定聯結以取得最佳效能的相關資訊，請參閱使用明確JOIN子句控制供需規劃員。

• MariaDB – 請參閱 MariaDB 文件中的查詢最佳化。

使用「我的」的最佳做法 SQL

我的資料庫中的資料表大小和SQL資料表數目都會影響效能。

資料表大小

通常，作業系統對檔案大小的限制會決定 [我的SQL資料庫] 的有效資料表大小上限。因此，限制通常不是由內部「我的」SQL 約束決定的。

在 My SQL DB 執行個體上，避免資料庫中的資料表變得太大。雖然一般儲存限制是 64 TiB，但佈建的儲存區限制會將我的SQL資料表檔案的大小上限限制為 16 TiB。請分割大型資料表，使得檔案大小不超過 16 TiB 的限制。此方法也可以改善效能和復原時間。如需詳細資訊，請參閱我在 Amazon 的SQL文件大小限制 RDS。

非常大的資料表 (大小超過 100 GB) 可能會對讀取和寫入 (包括DML陳述式和特別是DDL陳述式) 的效能產生負面影響。大型資料表上的索引可以顯著改善選取效能，但也會降低陳述式的DML效能。DDL對於大型資料表而言ALTER TABLE，陳述式 (例如) 可能會明顯變慢，因為在某些情況下，這些作業可能會完全重建資料表。這些DDL陳述式可能會在作業期間鎖定資料表。

My SQL 進行讀取和寫入所需的記憶體量取決於作業中涉及的資料表。這是一個最好的做法，至少有足RAM夠的保存活躍使用的表的索引。若要尋找在資料庫中的十個最大資料表和索引，請使用下列查詢：

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

表格數目

您的基礎檔案系統可能對代表資料表的檔案數量有所限制。但是，我SQL對表的數量沒有限制。儘管如此，無論這些表的大小如何，My SQL InnoDB 存儲引擎中的表總數都可能導致性能降低。若要限制作業系統的影響，您可以將資料表分割到相同 My SQL DB 執行個體中的多個資料庫。這樣做可能會限制目錄中的檔案數量，但無法解決整體問題。

當由於大量表（超過 10 萬個）而導致性能下降時，這是由於我SQL使用存儲文件（包括打開和關閉它們）引起的。若要解決這個問題，您可以增加 table_open_cache 和 table_definition_cache 參數的大小。但是，增加這些參數的值可能會大幅增加「我的SQL使用」的記憶體數量，甚至可能會使用所有可用的記憶體。如需詳細資訊，請參閱我的SQL文件中的我的SQL開啟與關閉表格的方式。

此外，太多的表格會顯著影響我的SQL啟動時間。全新關機和重新啟動和崩潰恢復都可能受到影響，尤其是在 My SQL 8.0 之前的版本中。

建議在資料庫執行個體中所有資料庫間的資料表總數少於 10,000 個資料表。如需 My SQL 資料庫中包含大量資料表的使用案例，請參閱 My SQL 8.0 中的一百萬個資料表。

儲存引擎

RDS適用於我的 Amazon 的還 point-in-time 原和快照還原功能SQL需要當機可復原的儲存引擎。僅 InnoDB 儲存引擎支援這些功能。雖然 My SQL 支援具有不同功能的多個儲存引擎，但並非所有引擎都針對損毀復原和資料耐久性進行最佳化。例如，我的ISAM儲存引擎不支援可靠的損毀復原，而且可能會阻止 point-in-time 還原或快照還原如預期運作。當我SQL在當機後重新啟動時，這可能會導致資料遺失或損毀。

InnoDB 是 Amazon RDS 上我的數據庫實例的推薦和受支持的SQL存儲引擎。InnoDB 執行個體也可以移轉至 Aurora，而我的ISAM執行個體則無法移轉。但是，如果您需要強大的全文搜索功能，我的ISAM表現優於 InnoDB。如果您仍然選擇使ISAM用 My and AmazonRDS，在某些快照還原功能的情況下，遵循中所述的步驟使用不支援的我的SQL儲存引擎進行自動備份可能會有所幫助。

如果要將現有的 My ISAM 表轉換為 InnoDB 表，則可以在我的文檔中使用將表從我的轉換ISAM為 InnoDB 中概述的過程。SQLMy ISAM 和 InnoDB 有不同的優點和短處，因此在執行此操作之前，您應該充分評估對應用程序進行切換的影響。

此外，Amazon 目前不支持聯合存儲引擎我RDSSQL的.

使用 Oracle 的最佳實務

資料表大小和 MariaDB 資料庫中的資料表數量可能會影響效能。

資料表大小

一般而言，作業系統對檔案大小的約束會決定 MariaDB 資料庫的有效資料表大小上限。所以，限制通常不是由內部 MariaDB 約束所決定的。

在 MariaDB 資料庫執行個體上，請避免讓資料庫中的資料表變得太大。雖然一般儲存體限制為 64 TiB，但佈建的儲存體限制會將 MariaDB 資料表檔案的大小上限限制在 16 TiB。請分割大型資料表，使得檔案大小不超過 16 TiB 的限制。此方法也可以改善效能和復原時間。

非常大的資料表 (大小超過 100 GB) 可能會對讀取和寫入 (包括DML陳述式和特別是DDL陳述式) 的效能產生負面影響。較大的表格上的索引可以顯著提高選擇的性能，但它們也可以降低語句的DML性能。DDL對於大型資料表而言ALTER TABLE，陳述式 (例如) 可能會明顯變慢，因為在某些情況下，這些作業可能會完全重建資料表。這些DDL陳述式可能會在作業期間鎖定資料表。

MariaDB 讀取和寫入所需的記憶體數量取決於操作中涉及的資料表。這是一個最好的做法，至少有足RAM夠的保存活躍使用的表的索引。若要尋找在資料庫中的十個最大資料表和索引，請使用下列查詢：

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

表格數目

您的基礎檔案系統可能對代表資料表的檔案數量有所限制。不過，MariaDB 對資料表的數量沒有限制。儘管這樣，MariaDB InnoDB 儲存引擎中的資料表總數可能會導致性能降低 (無論這些資料表的大小如何)。若要限制作業系統的影響，您可以將資料表分割到同一個 MariaDB 資料庫執行個體中的多個資料庫。這樣做可能會限制目錄中的檔案數量，但無法解決整體問題。

當由於大量的資料表 (超過 10,000) 而導致效能下降時，它是由使用儲存檔案的 MariaDB 所引起的。這項工作包括 MariaDB 開啟和關閉儲存檔案。若要解決這個問題，您可以增加 table_open_cache 和 table_definition_cache 參數的大小。不過，增加這些參數的值可能會顯著增加 MariaDB 使用的記憶體數量。它甚至可能使用所有可用的記憶體。如需詳細資訊，請參閱 MariaDB 文件中的最佳化 table_open_cache

此外，太多的資料表會顯著影響 MariaDB 啟動時間。正常關機和重新啟動和損壞復原都會受到影響。建議在資料庫執行個體中所有資料庫間的資料表總數少於一萬個資料表。

儲存引擎

RDS適用於 MariaDB 的 Amazon 還 point-in-time 原和快照還原功能需要當機可復原的儲存引擎。雖然 MariaDB 支援多種功能不盡相同的儲存引擎，但並非所有引擎的損毀復原能力和資料耐用性都經過最佳化設計。例如，雖然 Aria 是 My 的當機安全替代品ISAM，但它仍然可能會阻止還 point-in-time 原或快照還原如預期運作。這可能在損毀後，重新啟動 MariaDB 時造成資料遺失或損毀。InnoDB 是 Amazon 上 MariaDB 資料庫執行個體推薦且受支援的儲存引擎。RDS如果您仍然選擇將 Aria 與 Amazon 搭配使用RDS，在某些快照還原功能的情況下，遵循中所述的步驟利用不受支援的 MariaDB 儲存引擎進行自動備份可能會有所幫助。

如果要將現有的 My ISAM 表轉換為 InnoDB 表，則可以使用 MariaDB 文檔中將表從我的轉換ISAM為 InnoDB 中概述的過程。My ISAM 和 InnoDB 有不同的優點和短處，因此在執行此操作之前，您應該充分評估對應用程序進行切換的影響。

使用 Oracle 的最佳實務

如需使用適用於 Oracle 的 Amazon RDS 最佳實務的相關資訊，請參閱在亞馬遜網路服務上執行 Oracle 資料庫的最佳實務。

一年 AWS 虛擬研討會包括在 Amazon 上運行生產 Oracle 數據庫的演示文稿RDS。您可以在此處找到簡報的影片：

與波斯特格雷合作的最佳做法 SQL

在 Postgre 可以提高性能的兩個重要領域中SQL，一個是將數據加載到數據庫實例時。RDS另一種是使用後SQL自動真空功能時。下列小節涵蓋我們對這些時機的一些實務建議。

如需 Amazon 如何RDS實作其他常見 Postgre SQL DBA 任務的相關資訊，請參閱Amazon RDS for PostgreSQL 的常用 DBA 任務。

將資料載入後資料SQL庫執行個體

將資料載入RDS適用於 Postgre 資料SQL庫執行個體的 Amazon 時，請修改資料庫執行個體設定和資料庫參數群組值。設定這些項目可讓您以最有效率的方式將資料匯入至資料庫執行個體。

將資料庫執行個體設定修改為下列：

• 停用資料庫執行個體備份 (將 backup_retention 設為 0)

• 停用多個可用區

修改資料庫參數群組來包含下列設定。此外，測試參數設定，為資料庫執行個體找出最有效的設定：

• 增加 maintenance_work_mem 參數的值。如需 Postgre SQL 資源消耗參數的詳細資訊，請參閱 Postgre 文SQL件。

• 增加max_wal_size和checkpoint_timeout參數的值，以減少對預寫 log (WAL) 記錄的寫入次數。

• 停用 synchronous_commit 參數。

• 禁用後SQL自動真空參數。

• 確定已記錄任何您要匯入的資料表。存放在未記錄資料表的資料可能在容錯移轉期間遺失。如需詳細資訊，請參閱CREATETABLEUNLOGGED。

使用 pg_dump -Fc (壓縮) 或 pg_restore -j (平行) 命令搭配這些設定。

載入作業完成後，將資料庫執行個體和資料庫參數回復為正常設定。

使用後SQL自動真空功能

Postgre SQL 資料庫的自動真空功能是我們強烈建議您用來維護 Postgre SQL 資料庫執行個體健康狀態的功能。Autovacuum 自動執行VACUUM和ANALYZE命令使用自動真空是 Postgre 要求的SQL，而不是 Amazon RDS 強制執行的，它的使用對於良好的性能至關重要。預設情況下，所有適用於 Postgre SQL 資料庫執行個體RDS的新 Amazon 都會啟用此功能，並且預設會適當地設定相關組態參數。

您的資料庫管理員需要知道並了解此維護操作。有關自動真空的 Postgre SQL 文檔，請參閱自動真空守護程序。

自動清空不是「不耗用資源」的操作，但會在背景中運作並盡可能產生使用者操作。啟用時，自動清空會檢查有大量更新或刪除元組的資料表。由於交易 ID 包圍，它也會保護非常舊的資料，避免遭到遺失。如需詳細資訊，請參閱避免交易 ID 包圍失敗。

您不應將自動清空視為可以減少以獲得更好效能的高成本操作。相反地，如果自動清空未執行，更新和刪除速度快的資料表將隨著時間快速惡化。

重要

未執行自動清空最後可能會使得您必須停機，以執行更為侵入式的清空操作。在某些情況下，Postgre SQL 資料庫執行個RDS體可能因為過度保守使用自動真空而無法使用。在這些情況下，Postgre SQL 資料庫會關閉以保護自己。此時，Amazon RDS 必須直接在資料庫執行個體上執行 single-user-mode 完整真空。這種完全清空可能會造成系統停機好幾個小時。因此，強烈建議您不要關閉預設開啟的自動清空選項。

自動清空參數會判斷自動清空何時運作與運作強度。autovacuum_vacuum_threshold 和 autovacuum_vacuum_scale_factor 參數會判斷自動清空何時執行。autovacuum_max_workers、autovacuum_nap_time，autovacuum_cost_limit 和 autovacuum_cost_delay 參數會判斷自動清空的運作強度。有關自動真空，何時運行以及需要哪些參數的更多信息，請參閱 Postgre 文檔中的常規吸塵。SQL

以下的查詢顯示名為 table1 之資料表中「無效」元組的數量：

SELECT relname, n_dead_tup, last_vacuum, last_autovacuum FROM 
pg_catalog.pg_stat_all_tables 
WHERE n_dead_tup > 0 and relname = 'table1';

查詢的結果將類似下列：

relname | n_dead_tup | last_vacuum | last_autovacuum
---------+------------+-------------+-----------------
 tasks   |   81430522 |             |
(1 row) 

Amazon RDS 的SQL最佳實踐視頻

二零二零年 AWS RE: Invent 會議包括介紹了在 Amazon 上與 Post SQL gre 合作的新功能和最佳實踐。RDS您可以在此處找到簡報的影片：

使用SQL伺服器的最佳作法

使用 SQL Server 資料庫執行個體進行異地同步備份部署的最佳做法包括：

• 使用 Amazon RDS 資料庫事件監控容錯移轉。例如，在資料庫執行個體容錯移轉時，您可以透過文字訊息或電子郵件收到通知。如需 Amazon RDS 事件的詳細資訊，請參閱使用 Amazon RDS 事件通知。

• 如果您的應用程式快取DNS值，請將時間設定為 live (TTL) 小於 30 秒。TTL如果發生容錯移轉，這樣設定是一個很好的做法。在容錯移轉中，IP 地址可能變更且快取值可能不再提供服務。

• 建議您不要啟用下列模式，因為它們會關閉交易日誌，而這是多個可用區所需：

  • 簡單復原模式

  • 離線模式

  • 唯讀模式

• 測試以判斷您的資料庫執行個體進行容錯移轉所需的時間。容錯移轉的時間可能因資料庫的類型、執行個體類別和您使用的儲存類型而異。您也應該測試應用程式在發生容錯移轉時繼續運作的能力。

• 若要縮短容錯移轉時間，請執行下列動作：

  • 確定您已為工作負載IOPS配置足夠的佈建。不足的 I/O 可能加長容錯移轉時間。資料庫復原需要 I/O。

  • 使用較小的交易。資料庫復原仰賴於交易，因此，如果您可以將大型交易分成多個較小的交易，您的容錯移轉時間應該會縮短。

• 請注意，在容錯移轉期間，延遲可能延長。作為容錯移轉程序的一部分，Amazon RDS 會自動將您的資料複寫到新的備用執行個體。此複寫表示新資料正在遞交至兩個不同的資料庫執行個體。因此，直到備用資料庫執行個體追上新的主要資料庫執行個體之前，可能會有一些延遲。

• 在所有可用性區域中部署您的應用程式。如果可用性區域發生故障，您在其他可用性區域的應用程式仍將可用。

使用SQL伺服器的異地同步備份部署時，請記住，Amazon RDS 會為執行個體上的所有SQL伺服器資料庫建立複本。如果您不想要讓特定資料庫有次要複本，請為那些資料庫設定不使用多個可用區的個別資料庫執行個體。

Amazon SQL 服RDS務器最佳實踐視頻

二零一九年 AWS re: Invent 會議包括介紹了在 Amazon 上使用SQL服務器的新功能和最佳實踐。RDS您可以在此處找到簡報的影片：

使用資料庫參數群組

建議您在測試資料庫執行個體上嘗試進行資料庫參數群組變更，再將參數群組變更套用至生產資料庫執行個體。未正確設定資料庫參數群組中的資料庫引擎參數，可能產生各種意外影響，包括降低效能和系統不穩定。修改資料庫引擎參數時請務必謹慎，在修改資料庫參數群組之前，請備份您的資料庫執行個體。

如需備份資料庫執行個體的詳細資訊，請參閱備份、還原和匯出資料。

自動建立資料庫執行個體的最佳實務

使用偏RDS好的次要版本資料庫引擎建立資料庫執行個體是 Amazon 的最佳實務。您可以使用 AWS CLI，Amazon RDSAPI，或 AWS CloudFormation 自動建立資料庫執行個體。使用這些方法時，您只能指定主要版本，Amazon RDS 會自動建立具有偏好次要版本的執行個體。例如，如果 Postgre SQL 12.5 是偏好的次要版本，而且如果您使用指定版本 12create-db-instance，則資料庫執行個體將是 12.5 版。

若要決定偏好的次要版本，您可以使用以下範例所示 describe-db-engine-versions 的選項來執行命令 --default-only。

aws rds describe-db-engine-versions --default-only --engine postgres

{
    "DBEngineVersions": [
        {
            "Engine": "postgres",
            "EngineVersion": "12.5",
            "DBParameterGroupFamily": "postgres12",
            "DBEngineDescription": "PostgreSQL",
            "DBEngineVersionDescription": "PostgreSQL 12.5-R1",
            ...some output truncated...
        }
    ]
}

如需以程式設計方式建立資料庫執行個體的資訊，請參閱以下資源：

• 使用 AWS CLI – create-db-instance

• 使用 Amazon RDS API-C reateDBInstance

• 使用 AWS CloudFormation – AWS::RDS::DBInstance

Amazon RDS 新功能視頻

二二二三 AWS re：發明會議包括有關 Amazon 新功能的演示文稿。RDS您可以在此處找到簡報的影片：