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

消減負載

縮短回應時間並增加關鍵工作流程的可用資源可能需要消除無關負載。本節介紹的許多解決方案都是權衡決策。其會對應用程式產生影響，必須仔細考慮。在下列情況下，請考慮使用這些解決方案：

立即變更包括下列項目：

在執行這些動作之前，根據長期業務目標和風險進行評估。

分隔讀寫工作負載

在執行由 MySQL 提供支援的應用程式時，常見技術是將讀取操作從寫入器 (主要) 資料庫執行個體卸載到一或多個唯讀資料庫複本上。透過卸載讀取，您可以減少主要資料庫執行個體上的整體負載並為寫入騰出空間。請確保僅針對不依賴複本的立即 read-after-write 一致性的讀取。更有效的方法是將所有讀取流量移至複本，並規劃在複寫延遲時重試 read-after-write。存在可以卸載的獨立讀取工作負載，例如報告服務。其他讀取將需要在應用程式層級進行變更，其中發出讀取的內容是眾所周知的。

另一種方法是實作資料庫代理解決方案作為應用程式與資料庫之間的媒介，它可以提供讀寫分割和查詢路由的功能，而無需應用程式感知。ProxySQL、MariaDB MaxScale、ScaleARC 和 Heimdall Data 是一些可用的 MySQL 相容代理解決方案。這些產品提供多種其他功能，例如快取或連線多工。在您遇到流量突然激增並在應用程式堆疊中實作新技術時，我們建議您從分割讀取/寫入查詢的基本功能開始，並在使用可能產生意外副作用的其他功能之前測試行為和效能。

封存或清除較舊資料

另一種提高資料庫效能的技術是將歷史資料卸載至另一個資料表、資料庫或 Amazon Simple Storage Service (Amazon S3)。許多資料庫保留應用程式整個歷史記錄的所有內嵌資料。在一般情況下，在典型的面向使用者的應用程式中，這可讓使用者查看其所有歷史訂單。需求突然激增時，應用程式上的許多作用中使用者可能是新使用者或專注於下新訂單。如果歷史資料在線上駐留在包含數十億資料列的單一資料表中，則情況會更加複雜。此資料表還可能具有大型索引。資料表資料和索引都以樹狀目錄結構儲存。資料表中的項目越多，樹狀目錄的層級就越高，這需要更多 I/O 操作來存取資料列。這會增加尋找個別記錄的存取時間。更重要的是，它會導致索引的大量不必要的部分駐留在資料庫頁面快取 (InnoDB 緩衝集區) 中。

將較舊資料封存至個別資料表、個別資料庫或 Amazon S3 可以減少最終使用者的存取時間、釋放寶貴的快取並提高整體應用程式效能。在事件發生之前封存較舊資料 (例如，僅保留 30 天或 90 天) 會限制關鍵資料表上的資料表和索引的大小。此變更需要修改應用程式，以僅針對明確要求查看歷史資料的一小部分使用者從次要位置查詢較舊資料。

延遲非關鍵 ETL 程序

在超擴展條件下，從主要資料庫系統中擷取 ETL 程序可能會對高度交易和並行工作負載帶來穩定性風險。ETL 程序具有下列特性：

可變的或不可預測的 ETL 程序 (例如，INSERT INTO ... SELECT FROM ...;) 等查詢) 會新增至負載和爭用的整體可變性，從而增加穩定性風險。

在可能的情況下，延遲或降低 ETL 程序執行的頻率，尤其是在其不提供關鍵功能的情況下。對於重要 ETL 程序，進行修改，以便其在有界限的工作單位中操作，例如處理固定資料列數的批次 (例如，使用 LIMIT 子句)、使用獨立的交易，或者在較長的時間內提取少量資料，以減少資料庫執行個體的峰值資源需求。

關閉不太重要的應用程式功能

在處理大量請求時適當地降低使用者體驗或移除非核心功能，可以為關鍵功能節省資料庫資源。這可能需要對客戶體驗進行稍微變更，但不同的流程比網站關閉要好。也許可以暫時停用永遠進行資料庫呼叫的網站首頁上的個人化設定。或者，您可以在選擇產品時停止向回頭客提供自訂優惠。暫時關閉功能可以在不需要存取資料庫的情況下快取或交付頁面。

其他範例包括具有輪詢機制的前端，用於檢查需要資料庫呼叫的資料變更。降低輪詢頻率將立即導致資料庫呼叫減少。需要分頁或為使用者提供擷取遠離熱門搜尋結果的排序結果集的選項的使用者介面需要越來越昂貴的資料庫呼叫。限制結果集中的頁數以保護資料庫免受最昂貴的資料庫呼叫的影響。在應用程式層使用功能旗標，以讓營運團隊在應用程式或資料庫負載增加時關閉或降級功能。