本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # Amazon RDS 的最佳實務 了解使用 Amazon RDS 的最佳實務。在新最佳實務確定時，我們會不斷更新此小節。 **Topics** + [Amazon RDS 基本操作準則](#CHAP_BestPractices.DiskPerformance) + [資料庫執行個體 RAM 建議](#CHAP_BestPractices.Performance.RAM) + [將資料庫引擎版本保持在最新狀態](#CHAP_BestPractices.Upgrades) + [AWS 資料庫驅動程式](#CHAP_BestPractices.Drivers) + [使用 Enhanced Monitoring 來識別作業系統問題](#CHAP_BestPractices.EnhancedMonitoring) + [使用指標來識別效能問題](#CHAP_BestPractices.UsingMetrics) + [調校查詢](#CHAP_BestPractices.TuningQueries) + [使用 MySQL 的最佳實務](#CHAP_BestPractices.MySQLStorage) + [使用 Oracle 的最佳實務](#CHAP_BestPractices.MariaDB) + [使用 Oracle 的最佳實務](#CHAP_BestPractices.Oracle) + [使用 PostgreSQL 的最佳實務](#CHAP_BestPractices.PostgreSQL) + [使用 SQL Server 的最佳實務](#CHAP_BestPractices.SQLServer) + [使用資料庫參數群組](#CHAP_BestPractices.DBParameterGroup) + [自動建立資料庫執行個體的最佳實務](#CHAP_BestPractices.AutoDBCreation) + [Amazon RDS 新功能影片](#CHAP_BestPractices.Presentation) **注意** 如需 Amazon RDS 的常用建議，請參閱 [Amazon RDS 的建議](monitoring-recommendations.md)。 ## Amazon RDS 基本操作準則 下列是使用 Amazon RDS 時，每個使用者應遵循的基本操作準則。請注意，Amazon RDS 服務水準協議需要您遵循這些準則： + 使用指標監控您的記憶體、CPU、複本延遲和儲存體用量。您可以設定 Amazon CloudWatch 在使用模式變更或您的部署接近容量限制時通知您。這可讓您維護系統效能和可用性。 + 在您處理儲存容量限制時向上擴展資料庫執行個體。您應該在儲存體和記憶體中具有一些緩衝，以容納應用程式需求中未知的增加。 + 啟用自動備份並將備份時段設定在每日寫入 IOPS 較低的期間發生。此時備份對資料庫使用情況產生的干擾最少。 + 如果資料庫工作負載所需的 I/O 較您佈建得多，容錯移轉或資料庫失敗之後的復原將會很緩慢。若要增加資料庫執行個體的 I/O 容量，請執行下列任何或所有動作： + 遷移至具有高 I/O 容量的其他資料庫執行個體類別。 + 根據您需要的增加量而定，從磁帶儲存體轉換成一般用途或佈建 IOPS 儲存體。如需可用儲存體類型的詳細資訊，請參閱[Amazon RDS 儲存類型](CHAP_Storage.md#Concepts.Storage)。 如果轉換為佈建 IOPS 儲存體，請確定您也使用已針對佈建 IOPS 最佳化的資料庫執行個體類別。如需佈建的 IOPS 的詳細資訊，請參閱[佈建 IOPS SSD 儲存體](CHAP_Storage.md#USER_PIOPS)。 + 如果您已在使用佈建 IOPS 儲存體，請佈建額外的傳輸量容量。 + 如果您的用戶端應用程式正在快取資料庫執行個體的網域名稱服務 (DNS) 資料，請設定少於 30 秒的存活期 (TTL) 值。資料庫執行個體的基礎 IP 位址可能會在容錯移轉後變更。長時間快取 DNS 資料可能從而導致連線失敗。您的應用程式可能會嘗試連線到不再提供服務的 IP 地址。 + 測試資料庫執行個體的容錯移轉，以了解您的特定使用案例執行此程序需時多長。也會測試容錯移轉，以確保可存取您資料庫執行個體的應用程式，可以在容錯移轉發生之後，自動連線到新的資料庫執行個體。 ## 資料庫執行個體 RAM 建議 Amazon RDS 的效能最佳實務是配置足夠的 RAM，使得您的*工作集*幾乎能完全在記憶體中。工作集是您的執行個體經常使用的資料和索引。您越常使用資料庫執行個體，工作集會成長越多。 若要判斷您的工作集是否完全在記憶體中，請在資料庫執行個體處於低負載時檢查 ReadIOPS 指標 (使用 Amazon CloudWatch)。ReadIOPS 的值應該很小並且穩定。在某些情況下，將資料庫執行個體類別縱向擴展至擁有更多 RAM 的類別，這會導致 ReadIOPS 大幅下降。在這些情況下，您的工作集幾乎完全不在記憶體中。請繼續向上擴展，直到擴展操作之後 ReadIOPS 不再大幅下降，或 ReadIOPS 減少至非常小的數量為止。如需監控資料庫執行個體之指標的詳細資訊，請參閱[在 Amazon RDS 主控台中檢視指標](USER_Monitoring.md)。 ## 將資料庫引擎版本保持在最新狀態 定期升級資料庫引擎版本，以維護安全性、效能和合規。Amazon RDS 發行新的次要和主要版本，包括安全性修補程式、效能增強功能和新功能。執行過時的資料庫引擎可能會讓您的工作負載暴露在已知的漏洞、相容性問題，並減少 AWS 和 資料庫廠商的支援。 若要將中斷降至最低，請在計畫升級時考慮下列事項： + **在預備環境中測試** – 升級生產資料庫之前，請針對工作負載驗證新版本。 + **使用 Amazon RDS 受管升級** – 啟用自動次要版本升級，以便於修補。 + **排程主要版本升級** – 檢閱版本備註、測試應用程式相容性，以及規劃受控升級時段。 定期升級有助於確保您的資料庫保持安全、最佳化並符合 AWS 最佳實務。 ## AWS 資料庫驅動程式 我們建議使用 驅動程式 AWS 套件進行應用程式連線。這些驅動程式旨在支援更快的切換和容錯移轉時間，以及使用 AWS Secrets Manager AWS Identity and Access Management (IAM) 和聯合身分進行身分驗證。 AWS 驅動程式依賴監控資料庫執行個體狀態，並注意執行個體拓撲以判斷新的寫入器。相較於開放原始碼驅動程式的數十秒，此方法可將切換和容錯移轉時間縮短為短短幾秒。 隨著推出新的服務功能，驅動程式 AWS 套件的目標是內建支援這些服務功能。 如需詳細資訊，請參閱[使用 AWS 驅動程式連線至資料庫執行個體](CHAP_CommonTasks.Connect.md#RDS.Connecting.Drivers)。 ## 使用 Enhanced Monitoring 來識別作業系統問題 啟用「增強型監控」時，Amazon RDS 會即時提供執行資料庫執行個體在其上執行之作業系統 (OS) 的指標。您可以使用主控台來檢視資料庫執行個體的指標。您也可以在您所選的監控系統中利用來自 Amazon CloudWatch Logs 的增強型監控 JSON 輸出。如需增強型監控的詳細資訊，請參閱[使用增強型監控來監控作業系統指標](USER_Monitoring.OS.md)。 ## 使用指標來識別效能問題 若要識別由於資源不足和其他常見瓶頸造成的效能問題，您可以監控 Amazon RDS 資料庫執行個體的可用指標。 ### 檢視效能指標 您應該定期監控效能指標以查看各種時間範圍的平均值、最大值和最小值。如果這麼做，當效能降級時您便可以得知。您也可以針對特定指標臨界值設定 Amazon CloudWatch 警示，在達到這些臨界值便警示您。 為了對效能問題進行故障診斷，請務必了解系統的基礎效能。當您設定資料庫執行個體並使用一般工作負載執行它時，請擷取所有效能指標的平均值、最大值和最小值。以數個不同的間隔（例如，一小時、24 小時、一週、兩週）進行此操作。這可讓您了解正常運作情況為何。這有助於比較尖峰與離峰時段的操作。之後您可以使用此資訊來得知效能是否下降至標準層級之下。 如果使用多可用區域資料庫叢集，請監控寫入器資料庫執行個體上的最新交易與讀取器資料庫執行個體上最新套用交易之間的時間差異。這種差異被稱為*複本延遲*。如需詳細資訊，請參閱[複本延遲和多可用區域資料庫叢集](multi-az-db-clusters-concepts.md#multi-az-db-clusters-concepts-replica-lag)。 您可以在績效詳情儀表板中檢視組合的績效詳情和 CloudWatch 指標，並監控資料庫執行個體。若要使用此監控檢視，必須為您的資料庫執行個體開啟績效詳情。如需此監控檢視的相關資訊，請參閱 [使用 Performance Insights 儀表板檢視組合指標](Viewing_Unifiedmetrics.md)。 您可以針對特定時間區間建立效能分析報告，並檢視所識別出的洞見和解決問題的建議。如需詳細資訊，請參閱 [在 Performance Insights 中建立效能分析報告](USER_PerfInsights.UsingDashboard.AnalyzePerformanceTimePeriod.md)。 **檢視效能指標** 1. 登入 AWS 管理主控台 ，並在 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)：// 開啟 Amazon RDS 主控台。 1. 在導覽窗格中，選擇 **Databases (資料庫)**，然後選擇一個資料庫執行個體。 1. 選擇 **Monitoring (監控)**。 儀表板提供效能指標。這些指標預設為顯示過去三小時的資訊。 1. 使用右上角的編號按鈕，來切換至其他指標頁面，或調整設定以查看更多指標。 1. 選擇用來調整時間範圍的效能指標，以查看當日以外的資料。您可以變更 **Statistic (統計資料)**、**Time Range (時間範圍)** 和 **Period (期間)** 值來調整顯示的資訊。例如，您可能想要查看某個指標過去兩週每天的尖峰值。若是如此，請將 **Statistic** (統計資料) 設定為 **Maximum** (最大值)、將 **Time Range** (時間範圍) 設定為 **Last 2 Weeks** (過去 2 週)、將 **Period** (期間) 設定為 **Day** (日)。 您也可以使用 CLI 或 API 來檢視效能指標。如需更多詳細資訊，請參閱 [在 Amazon RDS 主控台中檢視指標](USER_Monitoring.md)。 ****設定 CloudWatch 警示**** 1. 登入 AWS 管理主控台 並開啟位於 https：//[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) 的 Amazon RDS 主控台。 1. 在導覽窗格中，選擇 **Databases (資料庫)**，然後選擇一個資料庫執行個體。 1. 選擇 **Logs & events (日誌和事件)**。 1. 在 **CloudWatch 警示** 區段，選擇 **Create alarm (建立警示)**。 ![\[建立警示對話方塊\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/UserGuide/images/CreateAlarm.png) 1. 針對 **寄送通知**，選擇 **Yes (是)**，針對 **Send notifications to (寄送通知至)**，選擇 **New email or SMS topic (新的電子郵件或 SMS 主題)**。 1. 針對 **Topic name (主題名稱)**，輸入通知的名稱，並針對 **With these recipients (含有以下收件人)**，輸入以逗號分隔的電子郵件地址或電話號碼清單。 1. 針對 **Metric (指標)**，選擇警示數統計資料和指標來設定。 1. 針對 **Threshold (臨界值)**，指定指標是否必須大於、小於或等於閾值，並指定閾值。 1. 針對 **Evaluation Period** (評估期間)，選擇警示的評估期間。針對 **consecutive period(s) of** (連續期間)，選擇臨界值必須符合才能觸發警示的期間。 1. 針對 **Name of alarm (警示名稱)**，輸入警示的名稱。 1. 選擇**Create Alarm** (建立警示)。 警示出現於 **CloudWatch 警示** 區段中。 ### 評估效能指標 資料庫執行個體有一些不同類別的指標，而如何判斷可接受的值取決於指標。 **CPU** + CPU 使用率 – 已使用的電腦處理容量之百分比。 **記憶體** + 可釋放的記憶體 – 資料庫執行個體可用的 RAM (以位元組為單位)。在監控標籤指標中會針對 CPU、記憶體和儲存體指標，將紅線標記在 75%。如果執行個體記憶體的耗用量經常超過該線，這表示您應該檢查工作負載或升級執行個體。 + 交換用量 – 資料庫執行個體使用了多少交換空間 (以位元組為單位)。 **磁碟空間** + 可用儲存空間 – 資料庫執行個體目前尚未使用的磁碟空間 (以 MB 為單位)。 **輸入/輸出操作** + 讀取 IOPS、寫入 IOPS – 磁碟讀取或寫入操作的每秒平均次數。 + 讀取延遲、寫入延遲 – 讀取或寫入操作的平均時間 (以毫秒為單位)。 + 讀取傳輸量、寫入傳輸量 – 每秒自磁碟讀取或寫入至其中的平均數量 (以 MB 為單位)。 + 佇列深度 – 等候寫入至磁碟或從其中讀取的 I/O操作數量。 **網路流量** + 網路接收輸送量、網路傳輸輸送量 – 每秒自資料庫執行個體來回傳送的網路流量速度 (以位元組為單位)。 **資料庫連線** + 資料庫連線 – 連線至資料庫執行個體的用戶端工作階段數量。 如需可用效能指標的個別詳細說明，請參閱[使用 Amazon CloudWatch 監控 Amazon RDS 指標](monitoring-cloudwatch.md)。 一般來說，效能指標的可接受值視您的基準為何，以及您的應用程式所做之事而定。調查距離基準的一致或趨勢變異。關於特定類型指標的建議如下所示： + **高 CPU 或 RAM 耗用量 –** CPU 或 RAM 耗用量的高值可能是適當的。例如，如果它們與應用程式的目標 (如輸送量或並行) 一致且是預期的，它們可能就是這樣。 + **磁碟空間消耗量 – **如果使用的空間持續保持在等於或高於總磁碟空間的 85%，請調查磁碟空間消耗量。看看從執行個體刪除資料或將資料封存至不同的系統來釋出空間是否可行。 + **網路流量** – 對於網路流量，請洽系統管理員，以了解您的網域網路和網際網路連線預期的輸送量。調查網路流量的傳輸量是否如預期一致地降低。 + **資料庫連線 –** 如果您看到大量使用者連線，同時執行個體效能下降且回應時間延長，請考慮限制資料庫連線。資料庫執行個體使用者連線的最佳數量，將因執行個體類別和要執行的操作複雜性而不同。若要判定資料庫連線的數目，請將資料庫執行個體與參數群組建立關聯。在此群組中，將 *User Connections* (使用者連線) 參數設定為 0 (無限制) 以外的值。您可以使用現有的參數群組或建立新的參數群組。如需更多詳細資訊，請參閱 [Amazon RDS 的參數群組](USER_WorkingWithParamGroups.md)。 + **IOPS 指標 –** IOPS 指標的預期值視磁碟規格和伺服器組態而定，因此請使用您的基準來了解何謂典型。調查值是否與您的基準一致地不同。為獲得最佳 IOPS 效能，請確定您的一般工作集將放入記憶體中，以將讀取和寫入操作降到最低。 對於效能指標的問題，改善效能的第一步是調整最常用和最昂貴的查詢。調整它們，以查看這樣做是否會降低系統資源的壓力。如需詳細資訊，請參閱[調校查詢](#CHAP_BestPractices.TuningQueries)。 如果您的查詢經過調整且問題仍然存在，請考慮升級您的 Amazon RDS [ 資料庫執行個體類別](Concepts.DBInstanceClass.md)。您可能將其升級至具有更多資源 (CPU、RAM、磁碟空間、網路頻寬、I/O 容量)，且與問題相關的類別。 ## 調校查詢 改善資料庫執行個體效能的一個最佳方式是調校最常使用與資源最密集的查詢。在這裡，您可以調整它們，讓它們的執行成本更便宜。如需有關改善查詢的資訊，請使用下列資源： + MySQL – 請參閱 MySQL 文件中的[最佳化 SELECT 陳述式](https://dev.mysql.com/doc/refman/8.0/en/select-optimization.html)。如需其他查詢調校資源，請參閱 [MySQL 效能調校和最佳化資源](http://www.mysql.com/why-mysql/performance/)。 + Oracle – 請參閱 Oracle 資料庫文件中的[資料庫 SQL 調校指南](https://docs.oracle.com/database/121/TGSQL/toc.htm)。 + SQL 伺服器 – 請參閱 Microsoft 文件中的[分析查詢](http://technet.microsoft.com/en-us/library/ms191227.aspx)。您也可以使用 Microsoft 文件中[系統動態管理檢視](https://docs.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/system-dynamic-management-views)中所述的與執行、索引和 I/O 相關的資料管理檢視 (DMV)，對 SQL Server 查詢問題進行故障診斷。 查詢調校的一般層面為建立有效的索引。如需資料庫執行個體的潛在索引改進，請參閱 Microsoft 文件中的 [Database Engine Tuning Advisor](https://docs.microsoft.com/en-us/sql/relational-databases/performance/database-engine-tuning-advisor)。如需在 RDS for SQL Server 上使用 Tuning Advisor 的資訊，請參閱[使用 Database Engine Tuning Advisor 分析 Amazon RDS for SQL Server 資料庫執行個體上的資料庫工作負載](Appendix.SQLServer.CommonDBATasks.Workload.md)。 + PostgreSQL – 請參閱 PostgreSQL 文件中的[使用 EXPLAIN](http://www.postgresql.org/docs/current/using-explain.html)，瞭解如何分析查詢計畫。您可以使用此資訊來修改查詢或基礎資料表以改善查詢效能。 有關如何在您的查詢中指定聯結以獲得最佳效能的資訊，請參閱[使用明確 JOIN 子句來控制計畫者](http://www.postgresql.org/docs/current/explicit-joins.html)。 + MariaDB – 請參閱 MariaDB 文件中的[查詢最佳化](https://mariadb.com/kb/en/mariadb/query-optimizations/)。 ## 使用 MySQL 的最佳實務 MySQL 資料庫中的資料表大小和數量都會影效能。 ### 資料表大小 一般而言，作業系統對檔案大小的約束會決定 MySQL 資料庫的有效資料表大小上限。所以，限制通常不是由內部 MySQL 約束所決定的。 在 MySQL 資料庫執行個體上，請避免讓資料庫中的資料表變得太大。雖然一般儲存體限制為 64 TiB，但佈建的儲存體限制會將 MySQL 資料表檔案的大小上限限制在 16 TiB。請分割大型資料表，使得檔案大小不超過 16 TiB 的限制。此方法也可以改善效能和復原時間。如需更多詳細資訊，請參閱 [Amazon RDS 中的 MySQL 檔案大小限制](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.Limits.FileSize)。 非常大型的資料表 (大小大於 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 如何開啟及關閉資料表](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html)。 此外，太多的資料表會顯著影響 MySQL 啟動時間。正常關機和重新啟動和損壞復原都會受到影響，尤其是在 MySQL 8.0 之前的版本中。 建議在資料庫執行個體中所有資料庫間的資料表總數少於 10,000 個資料表。對於 MySQL 資料庫中含有有大量資料表的使用案例，請參閱 [MySQL 8.0 中的一百萬個資料表](https://www.percona.com/blog/2017/10/01/one-million-tables-mysql-8-0/)。 ### 儲存引擎 Amazon RDS for MySQL 時間點還原和快照還原功能需要可復原損毀的儲存引擎。僅 InnoDB 儲存引擎支援這些功能。雖然 MySQL 支援多種功能不盡相同的儲存引擎，但並非所有引擎的損毀復原能力和資料耐用性都經過最佳化設計。例如，MyISAM 儲存引擎不支援可靠的損毀復原，並可能使得時間點還原或快照還原無法如預期般順利運作。這可能在損毀後，重新啟動 MySQL 時造成資料遺失或損毀。 InnoDB 為 Amazon RDS 上 MySQL 資料庫執行個體上建議和支援的儲存引擎。InnoDB 執行個體也可以遷移至 Aurora，而 MyISAM 執行個體則無法遷移。不過，如果您需要密集的全文搜尋功能，MyISAM 的效能優於 InnoDB。如果您仍選擇使用 MyISAM 搭配 Amazon RDS，則[利用不受支援的 MySQL 儲存引擎進行自動備份](Overview.BackupDeviceRestrictions.md)中說明的步驟，對某些快照還原功能案例而言，相當實用。 如果要將現有的 MyISAM 資料表轉換為 InnoDB 資料表，可以使用 MySQL 文件中[將資料表從 MyISAM 轉換為 InnoDB](http://dev.mysql.com/doc/refman/5.0/en/converting-tables-to-innodb.html) 中所述的程序。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\$1open\$1cache](https://mariadb.com/kb/en/optimizing-table_open_cache/) 此外，太多的資料表會顯著影響 MariaDB 啟動時間。正常關機和重新啟動和損壞復原都會受到影響。建議在資料庫執行個體中所有資料庫間的資料表總數少於一萬個資料表。 ### 儲存引擎 Amazon RDS for MariaDB 時間點還原和快照還原功能需要可復原損毀的儲存引擎。雖然 MariaDB 支援多種功能不盡相同的儲存引擎，但並非所有引擎的損毀復原能力和資料耐用性都經過最佳化設計。例如，雖然 Aria 是 MyISAM 的損毀安全功能替代方案，仍可能使得時間點還原或快照還原無法如預期般順利運作。這可能在損毀後，重新啟動 MariaDB 時造成資料遺失或損毀。InnoDB 為 Amazon RDS 上 MariaDB 資料庫執行個體上建議和支援的儲存引擎。如果您仍選擇使用 Aria 搭配 Amazon RDS，則[利用不受支援的 MariaDB 儲存引擎進行自動備份](Overview.BackupDeviceRestrictionsMariaDB.md)中說明的步驟，對某些快照還原功能案例而言，相當實用。 如果要將現有的 MyISAM 資料表轉換為 InnoDB 資料表，可以使用 MariaDB 文件中[將資料表從 MyISAM 轉換為 InnoDB](https://mariadb.com/kb/en/converting-tables-from-myisam-to-innodb/) 中所述的程序。MyISAM 和 InnoDB 各有優劣之處，以應用程式執行轉換作業之前，應先完整評估相關影響。 ## 使用 Oracle 的最佳實務 如需 Amazon RDS for Oracle 適用的最佳實務的相關資訊，請參閱[在 Amazon Web Services 上執行 Oracle 資料庫的最佳實務](https://docs.aws.amazon.com/aws-technical-content/latest/oracle-database-aws-best-practices/introduction.html)。 2020 年 AWS 虛擬研討會包括在 Amazon RDS 上執行生產 Oracle 資料庫的簡報。您可以在此處找到簡報的影片： [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/vpSWZx4-M-M/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/vpSWZx4-M-M) ## 使用 PostgreSQL 的最佳實務 您可以改善 RDS for PostgreSQL 效能的兩個重要時機，一是將資料載入至資料庫執行個體時。另一個是使用 PostgreSQL 自動清空功能時。下列小節涵蓋我們對這些時機的一些實務建議。 如需有關 Amazon RDS 如何執行其他常見 PostgreSQL DBA 任務的資訊，請參閱[Amazon RDS for PostgreSQL 的常用 DBA 任務](Appendix.PostgreSQL.CommonDBATasks.md)。 ### 將資料載入至 PostgreSQL 資料庫執行個體 將資料載入至 Amazon RDS for PostgreSQL 資料庫執行個體時，請修改資料庫執行個體設定和資料庫參數群組值。設定這些項目可讓您以最有效率的方式將資料匯入至資料庫執行個體。 將資料庫執行個體設定修改為下列： + 停用資料庫執行個體備份 (將 backup\$1retention 設為 0) + 停用多個可用區 修改資料庫參數群組來包含下列設定。此外，測試參數設定，為資料庫執行個體找出最有效的設定： + 增加 `maintenance_work_mem` 參數的值。如需 PostgreSQL 資源耗用量參數的詳細資訊，請參閱 [PostgreSQL 文件](http://www.postgresql.org/docs/current/runtime-config-resource.html)。 + 增加 `max_wal_size` 和 `checkpoint_timeout` 參數的值，以減少對預先寫入 (WAL) 日誌的寫入次數。 + 停用 `synchronous_commit` 參數。 + 停用 PostgreSQL 自動清空參數。 + 確定已記錄任何您要匯入的資料表。存放在未記錄資料表的資料可能在容錯移轉期間遺失。如需詳細資訊，請參閱 [CREATE TABLE UNLOGGED](https://www.postgresql.org/docs/current/sql-createtable.html)。 使用 `pg_dump -Fc` (壓縮) 或 `pg_restore -j` (平行) 命令搭配這些設定。 載入作業完成後，將資料庫執行個體和資料庫參數回復為正常設定。 ### 使用 PostgreSQL 自動清空功能 PostgreSQL 資料庫的自動清空功能為我們強烈建議您使用的功能，您可用來維護 PostgreSQL 資料庫執行個體的運作狀態。自動清空會自動執行 VACUUM 和 ANALYZE 命令；PostgreSQL 會要求使用自動清空 (而非由 Amazon RDS 強加)，其使用對良好效能而言非常重要。依預設，所有新的 Amazon RDS for PostgreSQL 資料庫執行個體都會啟用此功能，而且依預設會適當設定相關的組態參數。 您的資料庫管理員需要知道並了解此維護操作。如需關於自動清空的 PostgreSQL 文件，請參閱[自動清空協助程式](http://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM)。 自動清空不是「不耗用資源」的操作，但會在背景中運作並盡可能產生使用者操作。啟用時，自動清空會檢查有大量更新或刪除元組的資料表。由於交易 ID 包圍，它也會保護非常舊的資料，避免遭到遺失。如需詳細資訊，請參閱[避免交易 ID 包圍失敗](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND)。 您不應將自動清空視為可以減少以獲得更好效能的高成本操作。相反地，如果自動清空未執行，更新和刪除速度快的資料表將隨著時間快速惡化。 **重要** 未執行自動清空最後可能會使得您必須停機，以執行更為侵入式的清空操作。在某些情況下，RDS for PostgreSQL 資料庫執行個體可能會因為過度保守使用自動清空而變成無法使用。在這些情況下，PostgreSQL 資料庫會關閉以保護自己。屆時，Amazon RDS 必須直接在資料庫執行個體上，透過單一使用者模式執行完整清空。這種完全清空可能會造成系統停機好幾個小時。**因此，強烈建議您不要關閉預設開啟的自動清空選項。 自動清空參數會判斷自動清空何時運作與運作強度。`autovacuum_vacuum_threshold` 和 `autovacuum_vacuum_scale_factor` 參數會判斷自動清空何時執行。`autovacuum_max_workers`、`autovacuum_nap_time`，`autovacuum_cost_limit` 和 `autovacuum_cost_delay` 參數會判斷自動清空的運作強度。如需有關自動清空、何時執行以及需要什麼參數的詳細資訊，請參閱 PostgreSQL 文件中的[常式清空](https://www.postgresql.org/docs/current/routine-vacuuming.html)。 以下的查詢顯示名為 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 的新功能和最佳實務的簡報。您可以在此處找到簡報的影片： [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/3JLPWOoiVB8/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/3JLPWOoiVB8) ## 使用 SQL Server 的最佳實務 具有 SQL Server 資料庫執行個體之多個可用區部署的最佳實務包括下列： + 使用 Amazon RDS 資料庫事件來監控容錯移轉。例如，在資料庫執行個體容錯移轉時，您可以透過文字訊息或電子郵件收到通知。如需 Amazon RDS 事件的詳細資訊，請參閱[使用 Amazon RDS 事件通知](USER_Events.md)。 + 如果您的應用程式會快取 DNS 值，請將存留時間 (TTL) 設定為少於 30 秒。在發生容錯移轉時，以此方式設定 TTL 是很好的做法。在容錯移轉中，IP 地址可能變更且快取值可能不再提供服務。 + 建議您*不要*啟用下列模式，因為它們會關閉交易日誌，而這是多個可用區所需： + 簡單復原模式 + 離線模式 + 唯讀模式 + 測試以判斷您的資料庫執行個體進行容錯移轉所需的時間。容錯移轉的時間可能因資料庫的類型、執行個體類別和您使用的儲存類型而異。您也應該測試應用程式在發生容錯移轉時繼續運作的能力。 + 若要縮短容錯移轉時間，請執行下列動作： + 確保已為您的工作負載配置足夠的佈建 IOPS。不足的 I/O 可能加長容錯移轉時間。資料庫復原需要 I/O。 + 使用較小的交易。資料庫復原仰賴於交易，因此，如果您可以將大型交易分成多個較小的交易，您的容錯移轉時間應該會縮短。 + 請注意，在容錯移轉期間，延遲可能延長。在容錯移轉程序中，Amazon RDS 會將您的資料自動複寫至新的待命執行個體。此複寫表示新資料正在遞交至兩個不同的資料庫執行個體。因此，直到備用資料庫執行個體追上新的主要資料庫執行個體之前，可能會有一些延遲。 + 在所有可用性區域中部署您的應用程式。如果可用性區域發生故障，您在其他可用性區域的應用程式仍將可用。 使用 SQL Server 的多個可用區部署時，請記得，Amazon RDS 會為您的執行個體上的所有 SQL Server 資料庫建立複本。如果您不想要讓特定資料庫有次要複本，請為那些資料庫設定不使用多個可用區的個別資料庫執行個體。 ### Amazon RDS for SQL Server 最佳實務影片 2019 AWS re：Invent 會議包含有關在 Amazon RDS 上使用 SQL Server 的新功能和最佳實務的簡報。您可以在此處找到簡報的影片： [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/R4Vj88iqu5s/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/R4Vj88iqu5s) ## 使用資料庫參數群組 建議您在測試資料庫執行個體上嘗試進行資料庫參數群組變更，再將參數群組變更套用至生產資料庫執行個體。未正確設定資料庫參數群組中的資料庫引擎參數，可能產生各種意外影響，包括降低效能和系統不穩定。修改資料庫引擎參數時請務必謹慎，在修改資料庫參數群組之前，請備份您的資料庫執行個體。 如需備份資料庫執行個體的詳細資訊，請參閱[備份、還原和匯出資料](CHAP_CommonTasks.BackupRestore.md)。 ## 自動建立資料庫執行個體的最佳實務 使用偏好的資料庫引擎次要版本建立資料庫執行個體的 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... } ] } ``` 如需以程式設計方式建立資料庫執行個體的資訊，請參閱以下資源： + 使用 AWS CLI – [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) + 使用 Amazon RDS API – [ CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) + 使用 AWS CloudFormation – [AWS::RDS::DBInstance](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-rds-dbinstance.html) ## Amazon RDS 新功能影片 2023 AWS re：Invent 會議包含有關新 Amazon RDS 功能的簡報。您可以在此處找到簡報的影片： [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/IFg8EZGtLsM?si=e7T7LzW616AMd3i3/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/IFg8EZGtLsM?si=e7T7LzW616AMd3i3)