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

Amazon RDS 的最佳實務

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

Amazon RDS 基本操作準則

下列是使用 Amazon RDS 時，每個使用者應遵循的基本操作準則。請注意，Amazon RDS 服務水準協議需要您遵循這些準則：

資料庫執行個體 RAM 建議

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

若要判斷您的工作集是否完全在記憶體中，請在資料庫執行個體處於低負載時檢查 ReadIOPS 指標 (使用 Amazon CloudWatch)。ReadIOPS 的值應該很小並且穩定。在某些情況下，將資料庫執行個體類別縱向擴展至擁有更多 RAM 的類別，這會導致 ReadIOPS 大幅下降。在這些情況下，您的工作集幾乎完全不在記憶體中。請繼續向上擴展，直到擴展操作之後 ReadIOPS 不再大幅下降，或 ReadIOPS 減少至非常小的數量為止。如需監控資料庫執行個體之指標的詳細資訊，請參閱在 Amazon RDS主控台中檢視指標。

讓資料庫引擎版本保持最新

定期升級資料庫引擎版本，以維護安全性、效能和合規性。Amazon RDS 發行新的次要和主要版本，包括安全修補程式、效能增強功能和新功能。執行過時的資料庫引擎可能會讓您的工作負載暴露在已知的漏洞、相容性問題，並減少 AWS 和 資料庫廠商的支援。

若要將中斷降至最低，請在計劃升級時考慮下列事項：

定期升級有助於確保您的資料庫保持安全、最佳化並符合 AWS 最佳實務。

AWS 資料庫驅動程式

我們建議使用 AWS 驅動程式套件進行應用程式連線。這些驅動程式旨在提供更快的切換和容錯移轉時間支援，以及使用 AWS Secrets Manager AWS Identity and Access Management (IAM) 和聯合身分進行身分驗證。 AWS 驅動程式依賴監控資料庫執行個體狀態，並注意執行個體拓撲，以判斷新的寫入器。此方法會將切換和容錯移轉時間縮短為單位數秒，相較於開放原始碼驅動程式的數十秒。

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

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

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

啟用「增強型監控」時，Amazon RDS 會即時提供執行資料庫執行個體在其上執行之作業系統 (OS) 的指標。您可以使用主控台來檢視資料庫執行個體的指標。您也可以在您所選的監控系統中利用來自 Amazon CloudWatch Logs 的增強型監控 JSON 輸出。如需增強型監控的詳細資訊，請參閱使用增強型監控來監控作業系統指標。

使用指標來識別效能問題

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

檢視效能指標

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

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

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

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

您可以針對特定時間區間建立效能分析報告，並檢視所識別出的洞見和解決問題的建議。如需詳細資訊，請參閱 在績效詳情中建立績效分析報告。

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

警示出現於 CloudWatch 警示 區段中。

評估效能指標

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

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

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

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

如果您的查詢經過調整且問題仍然存在，請考慮升級您的 Amazon RDS 資料庫執行個體類別。您可能將其升級至具有更多資源 (CPU、RAM、磁碟空間、網路頻寬、I/O 容量)，且與問題相關的類別。

調校查詢

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

使用 MySQL 的最佳實務

MySQL 資料庫中的資料表大小和數量都會影效能。

資料表大小

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

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

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

MySQL 讀取和寫入所需的記憶體數量取決於操作中涉及的資料表。這是一個最佳實務，至少有足夠的 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;

表格數目

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

當因為大量的資料表（超過 1 萬）而導致效能下降時，它是由 MySQL 處理儲存文件引起的，包括開啟和關閉它們。若要解決這個問題，您可以增加 table_open_cache 和 table_definition_cache 參數的大小。但是，增加這些參數的值可能會顯著增加 MySQL 使用的記憶體數量，甚至可能會使用所有可用的記憶體。如需詳細資訊，請參閱 MySQL 文件中的 MySQL 如何開啟及關閉資料表。

此外，太多的資料表會顯著影響 MySQL 啟動時間。正常關機和重新啟動和損壞復原都會受到影響，尤其是在 MySQL 8.0 之前的版本中。

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

儲存引擎

Amazon RDS for MySQL 時間點還原和快照還原功能需要可復原損毀的儲存引擎。僅 InnoDB 儲存引擎支援這些功能。雖然 MySQL 支援多種功能不盡相同的儲存引擎，但並非所有引擎的損毀復原能力和資料耐用性都經過最佳化設計。例如，MyISAM 儲存引擎不支援可靠的損毀復原，並可能使得時間點還原或快照還原無法如預期般順利運作。這可能在損毀後，重新啟動 MySQL 時造成資料遺失或損毀。

InnoDB 為 Amazon RDS 上 MySQL 資料庫執行個體上建議和支援的儲存引擎。InnoDB 執行個體也可以遷移至 Aurora，而 MyISAM 執行個體則無法遷移。不過，如果您需要密集的全文搜尋功能，MyISAM 的效能優於 InnoDB。如果您仍選擇使用 MyISAM 搭配 Amazon RDS，則使用不支援的我的SQL儲存引擎進行自動備份中說明的步驟，對某些快照還原功能案例而言，相當實用。

如果您想要將現有的 MyISAM 資料表轉換為 InnoDB 資料表，您可以使用 MySQL 文件中將資料表從 MyISAM 轉換為 InnoDB 中概述的程序。MyISAM 和 InnoDB 各有優劣之處，以應用程式執行轉換作業之前，應先完整評估相關影響。

此外，Amazon RDS for MySQL 目前不支援聯合儲存引擎。

使用 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 啟動時間。正常關機和重新啟動和損壞復原都會受到影響。建議在資料庫執行個體中所有資料庫間的資料表總數少於一萬個資料表。

儲存引擎

Amazon RDS for MariaDB 時間點還原和快照還原功能需要可復原損毀的儲存引擎。雖然 MariaDB 支援多種功能不盡相同的儲存引擎，但並非所有引擎的損毀復原能力和資料耐用性都經過最佳化設計。例如，雖然 Aria 是 MyISAM 的損毀安全功能替代方案，仍可能使得時間點還原或快照還原無法如預期般順利運作。這可能在損毀後，重新啟動 MariaDB 時造成資料遺失或損毀。InnoDB 為 Amazon RDS 上 MariaDB 資料庫執行個體上建議和支援的儲存引擎。如果您仍選擇使用 Aria 搭配 Amazon RDS，則利用不受支援的 MariaDB 儲存引擎進行自動備份中說明的步驟，對某些快照還原功能案例而言，相當實用。

如果您想要將現有的 MyISAM 資料表轉換為 InnoDB 資料表，您可以使用 MariaDB 文件中將資料表從 MyISAM 轉換為 InnoDB 中概述的程序。MyISAM 和 InnoDB 各有優劣之處，以應用程式執行轉換作業之前，應先完整評估相關影響。

使用 Oracle 的最佳實務

如需 Amazon RDS for Oracle 適用的最佳實務的相關資訊，請參閱在 Amazon Web Services 上執行 Oracle 資料庫的最佳實務。

2020 年 AWS 虛擬研討會包含有關在 Amazon RDS 上執行生產 Oracle 資料庫的簡報。您可以在此處找到簡報的影片：

使用 PostgreSQL 的最佳實務

您可以改善 RDS for PostgreSQL 效能的兩個重要時機，一是將資料載入至資料庫執行個體時。另一個是使用 PostgreSQL 自動清空功能時。下列小節涵蓋我們對這些時機的一些實務建議。

如需有關 Amazon RDS 如何執行其他常見 PostgreSQL DBA 任務的資訊，請參閱Amazon RDS for PostgreSQL 的常用 DBA 任務。

將資料載入至 PostgreSQL 資料庫執行個體

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

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

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

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

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

使用 PostgreSQL 自動清空功能

PostgreSQL 資料庫的自動清空功能為我們強烈建議您使用的功能，您可用來維護 PostgreSQL 資料庫執行個體的運作狀態。自動清空會自動執行 VACUUM 和 ANALYZE 命令；PostgreSQL 會要求使用自動清空 (而非由 Amazon RDS 強加)，其使用對良好效能而言非常重要。依預設，所有新的 Amazon RDS for PostgreSQL 資料庫執行個體都會啟用此功能，而且依預設會適當設定相關的組態參數。

您的資料庫管理員需要知道並了解此維護操作。如需關於自動清空的 PostgreSQL 文件，請參閱自動清空協助程式。

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

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

自動清空參數會判斷自動清空何時運作與運作強度。autovacuum_vacuum_threshold 和 autovacuum_vacuum_scale_factor 參數會判斷自動清空何時執行。autovacuum_max_workers、autovacuum_nap_time，autovacuum_cost_limit 和 autovacuum_cost_delay 參數會判斷自動清空的運作強度。如需有關自動清空、何時執行以及需要什麼參數的詳細資訊，請參閱 PostgreSQL 文件中的常式清空。

以下的查詢顯示名為 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 for PostgreSQL 最佳實務影片

2020 AWS re：Invent 會議包含有關在 Amazon RDS 上使用 PostgreSQL 的新功能和最佳實務的簡報。您可以在此處找到簡報的影片：

使用 SQL Server 的最佳實務

具有 SQL Server 資料庫執行個體之多個可用區部署的最佳實務包括下列：

使用 SQL Server 的多個可用區部署時，請記得，Amazon RDS 會為您的執行個體上的所有 SQL Server 資料庫建立複本。如果您不想要讓特定資料庫有次要複本，請為那些資料庫設定不使用多個可用區的個別資料庫執行個體。

Amazon RDS for SQL Server 最佳實務影片

2019 AWS re：Invent 會議包含有關在 Amazon RDS 上使用 SQL Server 的新功能和最佳實務的簡報。您可以在此處找到簡報的影片：

使用資料庫參數群組

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

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

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

使用偏好的資料庫引擎次要版本建立資料庫執行個體的 Amazon RDS 最佳實務。您可以使用 AWS CLI、Amazon RDS API 或 AWS CloudFormation 來自動建立資料庫執行個體。使用這些方法時，您只能指定主要版本，因為 Amazon RDS 會使用偏好的次要版本自動建立執行個體。例如，如果 PostgreSQL 12.5 是偏好的次要版本，而且如果您使用 create-db-instance 指定 12 版，則資料庫執行個體將為 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...
        }
    ]
}

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

Amazon RDS 新功能影片

2023 AWS re：Invent 會議包含有關新 Amazon RDS 功能的簡報。您可以在此處找到簡報的影片：