本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
您可以應用以下最佳實務，改善 Aurora MySQL 叢集的效能和可擴展性。
主題
使用 T 執行個體類別進行開發和測試
對於不支援需時較長的高工作負載應用程式，使用 db.t2、db.t3 或 db.t4g 資料庫執行個體類別的 Amazon Aurora MySQL 執行個體是完美之選。T 執行個體旨在提供適度的基準效能和容量，可視您的工作負載需要大幅提升效能。它們適用非經常或持續使用整個 CPU，但偶爾需要高載的工作負載。建議您在開發、測試伺服器或其他非生產伺服器時，僅使用 T 資料庫執行個體類別。如需 T 執行個體類別的詳細資訊，請參閱爆量效能執行個體。
如果您的 Aurora 叢集大於 40 TB，請勿使用 T 執行個體類別。當您的資料庫有大量資料時，管理結構描述物件的記憶體額外負荷可能會超過 T 執行個體的容量。
請不要在 Amazon Aurora MySQL T 執行個體上啟用 MySQL Performance Schema (MySQL 效能結構描述)。如果已啟用 Performance Schema (效能結構描述)，執行個體可能會用盡記憶體。
提示
若您的資料庫有時處於閒置狀態，但有時工作負載相當大，則可使用 Aurora Serverless v2 作為 T 執行個體的替代方案。利用 Aurora Serverless v2，您可定義容量範圍，Aurora 會根據目前的工作負載自動擴展或縮小資料庫。如需用量詳細資料，請參閱 使用 Aurora Serverless v2。若需可與 Aurora Serverless v2 搭配使用的資料庫引擎版本，請參閱 的要求和限制 Aurora Serverless v2。
當您在 Aurora MySQL 資料庫叢集中，使用 T 執行個體作為資料庫執行個體時，我們建議下列作法：
-
在您的資料庫叢集中，所有執行個體請皆使用相同的資料庫執行個體類別。例如：如果您的寫入器執行個體使用
db.t2.medium，則我們也建議讀取器執行個體使用db.t2.medium。 -
請不要調整任何與記憶體相關的組態設定，例如
innodb_buffer_pool_size。Aurora 可針對 T 執行個體上的記憶體緩衝區使用一組高度調整的預設值。Aurora 需要這些特殊的預設值，才能在記憶體受限的執行個體上執行。如果您在 T 執行個體上變更任何與記憶體相關的設定，即使變更旨在增加緩衝區大小，也很可能會遇到記憶體不足的情況。 -
監控您的 CPU 點數餘額 (
CPUCreditBalance) 以確保它處於可永續使用的層級。也就是說，CPU 點數的累積速率與使用時速率相同。某個執行個體用盡 CPU 點數時，您會看到可用 CPU 立即下降，以及看到執行個體的讀寫延遲增加。此情況會造成執行個體整體效能嚴重降低。
如果您的 CPU 點數餘額未處於可永續使用的層級，建議您修改資料庫執行個體，以使用其中一個支援的 R 資料庫執行個體類別 (擴展運算)。
如需監控指標的詳細資訊，請參閱在 Amazon RDS主控台中檢視指標。
-
監控寫入器執行個體與讀取器執行個體之間的複本延遲 (
AuroraReplicaLag)。如果讀取器執行個體先於寫入器執行個體耗盡 CPU 點數，則產生的延遲可能會導致讀取器執行個體頻繁重新啟動。當應用程式分散在讀取器執行個體之間的讀取操作負載繁重，而同時寫入器執行個體有少量寫入操作時，此結果很常見。
如果您看到複本延遲持續增加，請確定資料庫叢集中讀取器執行個體的 CPU 點數餘額尚未用盡。
如果您的 CPU 點數餘額未處於可永續使用的層級，建議您修改資料庫執行個體，以使用其中一個支援的 R 資料庫執行個體類別 (擴展運算)。
-
針對已啟用二進位日誌的資料庫叢集，將每個交易的插入數保持在 100 萬個以下。
如果資料庫叢集的資料庫叢集參數群組的
binlog_format參數設為OFF以外的值，那麼，如果資料庫叢集收到的交易包含超過 100 萬個要插入的資料列，資料庫叢集可能會遇到記憶體不足情況。您可以監控可釋放記憶體 (FreeableMemory) 指標，以判斷資料庫叢集是否用盡可用的記憶體。然後可以檢查寫入操作 (VolumeWriteIOPS) 指標，以查看寫入器執行個體接收的寫入器操作負載是否繁重。若是這種情況，建議更新您的應用程式，將一個交易中的插入數限制在 100 萬個以下。或者，您可以修改執行個體，以使用其中一個支援的 R 資料庫執行個體類別 (擴展運算)。
使用非同步索引鍵預先提取，將 Amazon Aurora MySQL 索引聯結查詢最佳化
Aurora MySQL 可以使用非同步索引鍵預先提取 (AKP) 功能來改善聯結索引間資料表之查詢的效能。在 JOIN 查詢要求使用批次索引鍵存取 (BKA) 聯結演算法和多範圍讀取 (MRR) 最佳化功能的情況下，透過預期執行查詢所需的資料列，此功能可藉此改善效能。如需 BKA 和 MRR 的詳細資訊，請參閱 MySQL 文件中的封鎖巢狀迴圈和批次索引鍵存取聯結
若要利用 AKP 功能，查詢必須同時使用 BKA 和 MRR。一般來說，當查詢的 JOIN 子句使用次要索引，但也需要來自主要索引的一些資料欄時，會發生這類查詢。例如，當 JOIN 子句代表小型外部資料表與大型內部資料表間索引值的對等聯結，並且較大資料表上的索引具有高度選擇性時，您可以使用 AKP。AKP 可與 BKA 和 MRR 共同合作，以在 JOIN 子句的評估期間執行次要至主要索引查詢。AKP 會識別在 JOIN 子句的評估期間執行查詢所需的資料列。然後使用背景執行緒，在執行查詢之前，將包含那些資料列的頁面非同步載入至記憶體。
AKP 適用於 Aurora MySQL 第 2.10 版以上及第 3 版。如需 Aurora MySQL 版本的詳細資訊，請參閱 Amazon Aurora 我的數據庫引擎更新 SQL。
啟用非同步索引鍵預先提取
您可以透過將 MySQL 伺服器變數 aurora_use_key_prefetch 設定為 on 來啟用 AKP 功能。依預設，此值是設為 on。不過，在您也啟用 BKA 聯結演算法並停用成本型 MRR 功能之前，無法啟用 AKP。若要這麼做，您必須設定 MySQL 伺服器變數 optimizer_switch 的下列值：
-
將
batched_key_access設定為on。此值可控制 BKA 聯結演算法的使用。依預設，此值是設為off。 將
mrr_cost_based設定為off。此值可控制成本型 MRR 功能的使用。依預設，此值是設為on。
目前，您只能在工作階段層級設定這些值。下列範例說明如何透過執行 SET 陳述式來設定這些值，來為目前的工作階段啟用 AKP。
mysql> set @@session.aurora_use_key_prefetch=on;
mysql> set @@session.optimizer_switch='batched_key_access=on,mrr_cost_based=off';
相同地，您可以使用 SET 陳述式來停用 AKP 和 BKA 聯結演算法，以及為目前的工作階段重新啟用成本型 MRR 功能，如以下範例所示。
mysql> set @@session.aurora_use_key_prefetch=off;
mysql> set @@session.optimizer_switch='batched_key_access=off,mrr_cost_based=on';
如需 batched_key_access 和 mrr_cost_based 最佳化器切換參數的詳細資訊，請參閱 MySQL 文件中的可切換的最佳化
非同步索引鍵預先提取的最佳化查詢
您可以確認查詢是否可利用 AKP 功能。若要這麼做，請使用 EXPLAIN 陳述式在執行查詢之前描繪查詢。EXPLAIN 陳述式提供要針對指定查詢使用之執行計劃的相關資訊。
在 EXPLAIN 陳述式的輸出中，Extra 資料欄說明執行計劃隨附的其他資訊。如果 AKP 功能適用於查詢中使用的資料表，此資料欄會包括以下其中一個值：
Using Key PrefetchingUsing join buffer (Batched Key Access with Key Prefetching)
下列範例示範使用 EXPLAIN 來檢視可利用 AKP 之查詢的執行計劃。
mysql> explain select sql_no_cache
-> ps_partkey,
-> sum(ps_supplycost * ps_availqty) as value
-> from
-> partsupp,
-> supplier,
-> nation
-> where
-> ps_suppkey = s_suppkey
-> and s_nationkey = n_nationkey
-> and n_name = 'ETHIOPIA'
-> group by
-> ps_partkey having
-> sum(ps_supplycost * ps_availqty) > (
-> select
-> sum(ps_supplycost * ps_availqty) * 0.0000003333
-> from
-> partsupp,
-> supplier,
-> nation
-> where
-> ps_suppkey = s_suppkey
-> and s_nationkey = n_nationkey
-> and n_name = 'ETHIOPIA'
-> )
-> order by
-> value desc;
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
| 1 | PRIMARY | nation | ALL | PRIMARY | NULL | NULL | NULL | 25 | 100.00 | Using where; Using temporary; Using filesort |
| 1 | PRIMARY | supplier | ref | PRIMARY,i_s_nationkey | i_s_nationkey | 5 | dbt3_scale_10.nation.n_nationkey | 2057 | 100.00 | Using index |
| 1 | PRIMARY | partsupp | ref | i_ps_suppkey | i_ps_suppkey | 4 | dbt3_scale_10.supplier.s_suppkey | 42 | 100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
| 2 | SUBQUERY | nation | ALL | PRIMARY | NULL | NULL | NULL | 25 | 100.00 | Using where |
| 2 | SUBQUERY | supplier | ref | PRIMARY,i_s_nationkey | i_s_nationkey | 5 | dbt3_scale_10.nation.n_nationkey | 2057 | 100.00 | Using index |
| 2 | SUBQUERY | partsupp | ref | i_ps_suppkey | i_ps_suppkey | 4 | dbt3_scale_10.supplier.s_suppkey | 42 | 100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
6 rows in set, 1 warning (0.00 sec)
如需 EXPLAIN 輸出格式的詳細資訊，請參閱 MySQL 文件中的延伸 EXPLAIN 輸出格式
使用雜湊聯結，將大型 Aurora MySQL 聯結查詢最佳化
需要使用對等聯結來聯結大量資料時，雜湊聯結可以改善查詢效能。您可以為 Aurora MySQL 啟用雜湊聯結。
雜湊聯結資料欄可以是任何複雜的表達式。在雜湊聯結資料欄中，您可以利用下列方式來比較各個資料類型：
-
您可以比較各類別的精確數值資料類型項目，例如
int、bigint、numeric和bit。 -
您可以比較各類別的近似數值資料類型項目，例如
float和double。 -
您可以比較各字串類型的項目，以得知字串類型是否有相同的字元集和定序。
-
您可以比較項目的日期和時間戳記資料類型，以得知類型是否相同。
注意
您無法在不同類別中比較資料類型。
下列限制適用 Aurora MySQL 的雜湊聯結：
-
Aurora MySQL 第 2 版不支援左右外部連接，但第 3 版支援。
-
不支援半聯結 (例如子查詢)，除非先將子查詢具體化。
-
不支援多資料表更新或刪除。
注意
支援單一資料表更新或刪除。
-
BLOB 和空間資料類型資料欄不可為雜湊聯結中的聯結資料欄。
啟用雜湊聯結
若要啟用雜湊聯結：
-
Aurora MySQL 第 2 版 — 將資料庫參數或資料庫叢集參數
aurora_disable_hash_join設為0。若關閉aurora_disable_hash_join，optimizer_switch的值將為hash_join=on。 -
Aurora MySQL 第 3 版 — 將 MySQL 伺服器參數
optimizer_switch設為block_nested_loop=on。
雜湊聯結在 Aurora MySQL 第 3 版中會預設開啟，在 Aurora MySQL 第 2 版則預設關閉。下列範例說明如何為 Aurora MySQL 第 3 版啟用雜湊聯結。您可以發出陳述式 select @@optimizer_switch，以查看哪些其他設定存在於 SET 參數字串中。更新 optimizer_switch 參數中的某個設定不會清除或修改其他設定。
mysql> SET optimizer_switch='block_nested_loop=on';注意
對於 Aurora MySQL 第 3 版，雜湊聯結支援適用於所有次要版本，預設為開啟。
對於 Aurora MySQL 第 2 版，雜湊聯結支援適用於所有次要版本。在 Aurora MySQL 第 2 版中，雜湊聯結功能一律由 aurora_disable_hash_join 值控制。
利用此設定，最佳化器會根據成本、查詢特質和資源可用性選擇使用雜湊聯結。如果成本估算不正確，您可以強制最佳化器選擇某個雜湊聯結。您可以透過將 MySQL 伺服器變數 hash_join_cost_based 設定為 off 來執行此動作。下列範例說明如何強制最佳化器選擇雜湊聯結。
mysql> SET optimizer_switch='hash_join_cost_based=off';
注意
此設定會覆寫成本類型最佳化工具的決策。雖然該設定對於測試和開發非常有用，但建議您不要在生產環境中使用它。
最佳化雜湊聯結的查詢
若要了解查詢是否可利用雜湊聯結，請先使用 EXPLAIN 陳述式來描繪查詢。EXPLAIN 陳述式提供要針對指定查詢使用之執行計劃的相關資訊。
在 EXPLAIN 陳述式的輸出中，Extra 資料欄說明執行計劃隨附的其他資訊。如果雜湊聯結適用於查詢中所用的資料表，此資料欄會包括類似以下的值：
Using where; Using join buffer (Hash Join Outer tabletable1_name)Using where; Using join buffer (Hash Join Inner tabletable2_name)
下列範例示範使用 EXPLAIN 來檢視雜湊聯結查詢的執行計劃。
mysql> explain SELECT sql_no_cache * FROM hj_small, hj_big, hj_big2
-> WHERE hj_small.col1 = hj_big.col1 and hj_big.col1=hj_big2.col1 ORDER BY 1;
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
| 1 | SIMPLE | hj_small | ALL | NULL | NULL | NULL | NULL | 6 | Using temporary; Using filesort |
| 1 | SIMPLE | hj_big | ALL | NULL | NULL | NULL | NULL | 10 | Using where; Using join buffer (Hash Join Outer table hj_big) |
| 1 | SIMPLE | hj_big2 | ALL | NULL | NULL | NULL | NULL | 15 | Using where; Using join buffer (Hash Join Inner table hj_big2) |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
3 rows in set (0.04 sec)
在輸出中，Hash Join Inner table 是用來建置雜湊資料表的資料表，而 Hash Join Outer table 是用來探測雜湊資料表的資料表。
如需延伸 EXPLAIN 輸出格式的詳細資訊，請參閱 MySQL 產品文件中的延伸 EXPLAIN 輸出格式
在 Aurora MySQL 2.08 及更高版本中，您可以使用 SQL 提示來影響查詢是否使用雜湊聯結，以及要使用哪些資料表來建置和聯結探測端。如需詳細資訊，請參閱Aurora 我的SQL提示。
使用 Amazon Aurora 為 MySQL 資料庫擴展讀取
您可以使用 Amazon Aurora 搭配 MySQL 資料庫執行個體來利用 Amazon Aurora 的讀取擴展功能，並為 MySQL 資料庫執行個體擴展讀取工作負載。若要使用 Aurora 來讀取擴展 MySQL 資料庫執行個體，請建立 Aurora MySQL 資料庫叢集，並讓它成為您 MySQL DB 執行個體的讀取複本。然後連線至 Aurora MySQL 叢集以處理讀取查詢。該來源資料庫可以是 RDS for MySQL 資料庫執行個體，也可以是在 Amazon RDS 外部執行的 MySQL 資料庫。如需詳細資訊，請參閱使用 Amazon Aurora 擴展您的我的SQL資料庫的讀取。
最佳化時間戳記操作
當系統變數 time_zone 的值設為 SYSTEM 時，每個需要時區計算的 MySQL 函數呼叫都會進行系統程式庫呼叫。當您執行以高並行方式傳回或變更這類 TIMESTAMP 值的 SQL 陳述式時，可能會遇到延遲、鎖定爭用和 CPU 使用率增加的情況。如需詳細資訊，請參閱 MySQL 文件中的 time_zone
若要避免此行為，建議您將 time_zone 資料庫叢集參數的值變更為 UTC。如需詳細資訊，請參閱在 Amazon Aurora 中修改資料庫叢集參數群組中的參數。
儘管 time_zone 參數是動態的 (不需要重新啟動資料庫伺服器)，但新值僅用於新連線。若要確保所有連線都更新為使用新的 time_zone 值，建議您在更新資料庫叢集參數之後回收應用程式連線。
虛擬索引 ID 溢位錯誤
Aurora MySQL 會將虛擬索引 IDs 的值限制為 8 位元，以防止 MySQL 中復原格式造成的問題。如果索引超過虛擬索引 ID 限制，您的叢集可能無法使用。當索引接近虛擬索引 ID 限制，或當您嘗試建立超過虛擬索引 ID 限制的索引時，RDS 可能會擲出錯誤碼63955或警告碼 63955。若要解決虛擬索引 ID 限制錯誤，建議您使用邏輯傾印和還原來重新建立資料庫。
如需 Amazon Aurora MySQL 邏輯傾印和還原的詳細資訊，請參閱使用 MyDumper 和 MyLoader 將非常大型的資料庫遷移至 Amazon Aurora MySQL
