本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 調校查詢工作負載
妥善調校的工作負載將協助您實現超速成長的穩定解決方案。如果您的工作負載未妥善調校，無論您使用的 Amazon Aurora 叢集的功能如何，您都會遇到瓶頸，從而降低效能並影響應用程式的使用者體驗。最佳實務是從一開始就制定一個程序，協助您識別和調校系統中有問題的查詢。
## 追蹤和調校工作負載中有問題的查詢
發現超速成長時，妥善調校的工作負載就已成功一半。若要了解 Aurora 叢集面臨的即時工作負載和效能問題的性質，請確保您的團隊從寫入器和讀取器執行個體收集有問題的查詢。需要調校這些有問題的查詢，以使您的工作負載以最佳狀態執行。Amazon Aurora MySQL 為您提供了兩種方法來實現此目的：
+ Performance Insights
+ 慢速查詢日誌
**使用 Performance Insights**
Performance Insights 根據平均作用中工作階段數 (AAS) 追蹤 Aurora 寫入器或讀取器執行個體上的負載。AAS 值是透過使用取樣和等待 CPU 來取得查詢工作負載並進行處理的作用中工作階段數來計算的。Performance Insights 提供圖形介面，您可以透過等待作用中工作階段來檢查導致最高負載的 SQL 陳述式。
在上一個螢幕擷取畫面中，對儲存程序 `my_sqrt` 的呼叫導致平均 13.03 個工作階段等待其負載得到處理。合乎邏輯的下一步是調校此程序。您應識別讀取器和寫入器中導致各自執行個體負載的 SQL 陳述式，並進行調校以提高效能，直到 AAS 值下降並保持在 Performance Insights 中的 vCPU 數上限虛線以下。如果您的調校工作已達到上限，但仍看到 AAS 超過 vCPU 數上限線，則您可以選擇更大的執行個體類別來處理您的工作負載。在沒有先嘗試調校查詢工作負載的情況下，請勿選擇更大的執行個體，因為不斷增長的流量將開始暴露由工作負載中的錯誤查詢造成的故障線。
**使用慢速查詢日誌並將其發佈至 CloudWatch**
慢速查詢日誌是原生 MySQL 功能，是 Performance Insights 的補充。最佳實務是同時使用這兩種方法來提前解決可能對您的執行個體造成嚴重破壞的有問題的查詢。慢速查詢日誌記錄比動態變數 `long_query_time` 更慢的任何查詢。無需重新啟動叢集執行個體即可設定此變數。
為了在調校練習中提供靈活性和隔離性，請為寫入器和讀取器執行個體使用單獨的參數群組。如果您使用讀寫分割，這一點尤其重要。根據您的需求為叢集執行個體中的 `long_query_time` 設定適當的限制。調校負載時，您能以 `long_query_time` 變數中的主動值為目標，因為您能以毫秒級設定閾值。透過高度並行和妥善調校的工作負載，幾乎所有查詢都應在幾毫秒內執行。
在您設定 Amazon Aurora MySQL 相容版以將慢速查詢記錄至檔案時，Aurora MySQL 相容會將慢速查詢日誌寫入 Aurora MySQL 相容檔案系統並保留 24 小時。若要將慢速查詢日誌保留更長時間以進行分析，請將其發佈至 Amazon CloudWatch。您也可以建置 CloudWatch 儀表板來監控慢速查詢。如需詳細資訊，請參閱部落格文章[建立 Amazon CloudWatch 儀表板來監控 Amazon RDS 和 Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/creating-an-amazon-cloudwatch-dashboard-to-monitor-amazon-rds-and-amazon-aurora-mysql/)。除了分析 Amazon CloudWatch 上的慢速查詢之外，您還可以使用 [Percona Toolkit](https://www.percona.com/doc/percona-toolkit/LATEST/pt-query-digest.html) 中的工具 pt-query-digest 來分析慢速查詢日誌。
您也可以選擇自動執行此下載和分析查詢的程序，以提高團隊的效率。您的團隊應檢查頻繁執行且間隔較長的查詢，並排定調校的優先順序。目標是在慢速查詢日誌中記錄很少的查詢，並且在了解和調校工作負載時，您可以減少 `long_query_time` 以變得更積極。