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

Aurora 的最佳做法我的SQL效能和擴展

您可以套用下列最佳做法來改善 Aurora My SQL 叢集的效能和延展性。

使用 T 執行個體類別進行開發和測試

使用db.t2、db.t3或db.t4g資料庫SQL執行個體類別的 Amazon Aurora My 執行個體最適合長時間不支援高工作負載的應用程式。T 執行個體旨在提供適度的基準效能和容量，可視您的工作負載需要大幅提升效能。它們適用於不CPU經常或一致地使用完整功能，但偶爾需要爆發的工作負載。建議您在開發、測試伺服器或其他非生產伺服器時，僅使用 T 資料庫執行個體類別。如需 T 執行個體類別的詳細資訊，請參閱爆量效能執行個體。

如果您的 Aurora 叢集大於 40 TB，請勿使用 T 執行個體類別。當您的資料庫有大量資料時，管理結構描述物件的記憶體額外負荷可能會超過 T 執行個體的容量。

請勿在 Amazon Aurora 我的 SQL T 執行個體上啟用我的SQL效能結構描述。如果已啟用 Performance Schema (效能結構描述)，執行個體可能會用盡記憶體。

當您在 Aurora My DB 叢集中使用 T 執行個體做為資SQL料庫執行個體時，建議您執行下列操作：

使用非同步金鑰預取最佳化 Aurora 我的SQL索引聯結查詢

Aurora My SQL 可以使用非同步金鑰 prefetch (AKP) 功能來改善跨索引聯結資料表的查詢效能。此功能可預期執行查詢所需的資料列，其中JOIN查詢需要使用批次金鑰存取 (BKA) 聯結演算法和多範圍讀取 () 最佳化功能，藉此改善效能。MRR如需BKA和的詳細資訊MRR，請參閱 My 文件中的封鎖巢狀迴圈和批次金鑰存取聯結和多範圍讀取最佳化。SQL

若要利用AKP此功能，查詢必須同時使用BKA和MRR。一般而言，當查詢JOIN子句使用次要索引，但也需要主索引中的某些資料行時，就會發生這種查詢。例如，AKP當JOIN子句代表小型外部和大型內部表格之間索引值的等值連接時，您可以使用，並且索引在較大的資料表上具有高度選擇性。AKP在評估JOIN條款期間，配合使用BKA並MRR執行次要至主要索引查閱。AKP識別在評估JOIN子句期間執行查詢所需的資料列。然後使用背景執行緒，在執行查詢之前，將包含那些資料列的頁面非同步載入至記憶體。

AKP可用於 Aurora 我的SQL版本 2.10 及更高版本，以及版本 3。如需 Aurora 我的SQL版本的詳細資訊，請參閱Amazon Aurora 我的數據庫引擎更新 SQL。

啟用非同步索引鍵預先提取

您可以將 [我的SQL伺服器變數] 設定aurora_use_key_prefetch為來啟用AKP此功能on。依預設，此值是設為 on。不過，除非您同時啟用「BKA聯結」演算法並停用AKP以成本為基礎的MRR功能，否則無法啟用。若要這麼做，您必須為 optimizer_switch My SQL Server 變數設定下列值：

目前，您只能在工作階段層級設定這些值。下列範例說明如何透過執行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 Join 演算法，並重新啟用目前階段作業的成本基礎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_ 型最佳化程式參數的詳細資訊，請參閱我的文件中的可切換最佳化。 SQL

非同步索引鍵預先提取的最佳化查詢

您可以確認查詢是否可以利用AKP此功能。若要這麼做，請使用 EXPLAIN 陳述式在執行查詢之前描繪查詢。EXPLAIN 陳述式提供要針對指定查詢使用之執行計劃的相關資訊。

在 EXPLAIN 陳述式的輸出中，Extra 資料欄說明執行計劃隨附的其他資訊。如果此AKP功能適用於查詢中使用的資料表，則此欄會包含下列其中一個值：

下列範例顯示如何使用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輸出格式的詳細資訊，請參閱我的SQL文件中的延伸EXPLAIN輸出格式。

最佳化大型 Aurora 我SQL使用雜湊聯結的聯接查

需要使用對等聯結來聯結大量資料時，雜湊聯結可以改善查詢效能。您可以為我的 Aurora 啟用雜湊聯結SQL。

雜湊聯結資料欄可以是任何複雜的表達式。在雜湊聯結資料欄中，您可以利用下列方式來比較各個資料類型：

下列限制適用於 Aurora My 的雜湊聯結SQL：

啟用雜湊聯結

若要啟用雜湊聯結：

Aurora 我的SQL版本 3 中預設會開啟雜湊聯結，並在 Aurora 我的SQL版本 2 中預設關閉。下列範例說明如何為 Aurora 我的SQL版本 3 啟用雜湊聯結。您可以發出陳述式 select @@optimizer_switch，以查看哪些其他設定存在於 SET 參數字串中。更新 optimizer_switch 參數中的某個設定不會清除或修改其他設定。

mysql> SET optimizer_switch='block_nested_loop=on';

利用此設定，最佳化器會根據成本、查詢特質和資源可用性選擇使用雜湊聯結。如果成本估算不正確，您可以強制最佳化器選擇某個雜湊聯結。您可以透過將 [我的SQL伺服器變數] 設定hash_join_cost_based為off。下列範例說明如何強制最佳化器選擇雜湊聯結。

mysql> SET optimizer_switch='hash_join_cost_based=off';

最佳化雜湊聯結的查詢

若要了解查詢是否可利用雜湊聯結，請先使用 EXPLAIN 陳述式來描繪查詢。EXPLAIN 陳述式提供要針對指定查詢使用之執行計劃的相關資訊。

在 EXPLAIN 陳述式的輸出中，Extra 資料欄說明執行計劃隨附的其他資訊。如果雜湊聯結適用於查詢中所用的資料表，此資料欄會包括類似以下的值：

下面的例子顯示了如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輸出格式的詳細資訊，請參閱我的SQL產品文件中的延伸EXPLAIN輸出格式。

在 Aurora My SQL 2.08 及更高版本中，您可以使用SQL提示來影響查詢是否使用雜湊聯結，以及要用於聯結的建置和探查端的資料表。如需詳細資訊，請參閱 Aurora 我的SQL提示。

使用 Amazon Aurora 擴展我的SQL資料庫的讀取

您可以將 Amazon Aurora 與我的SQL資料庫執行個體搭配使用，以利用 Amazon Aurora 的讀取擴展功能，並擴展 My SQL 資料庫執行個體的讀取工作負載。若要使用 Aurora 讀取擴展您的 My SQL 資料庫執行個體，請建立 Aurora My SQL DB 叢集，並將其設為 My 資SQL料庫執行個體的僅供讀取複本。然後連接至 Aurora 我的SQL叢集以處理讀取查詢。來源資料庫可以是我的RDS資料SQL庫執行個體，也可以是 Amazon 外部執行的 My SQL 資料庫RDS。如需詳細資訊，請參閱使用 Amazon Aurora 擴展您的我的SQL資料庫的讀取。

最佳化時間戳記操作

當系統變數的值設定time_zone為時SYSTEM，每個需要時區計算的 My SQL 函數呼叫都會進行系統程式庫呼叫。當您執行以高度並行傳回或變更這類TIMESTAMP值的SQL陳述式時，您可能會遇到延遲、鎖定爭用和CPU使用量增加的陳述式。如需詳細資訊，請參閱我的文件中的 SQLtime_zone。

若要避免此行為，建議您將 time_zone 資料庫叢集參數的值變更為 UTC。如需詳細資訊，請參閱在 Amazon Aurora 中修改資料庫叢集參數群組中的參數。

儘管 time_zone 參數是動態的 (不需要重新啟動資料庫伺服器)，但新值僅用於新連線。若要確保所有連線都更新為使用新的 time_zone 值，建議您在更新資料庫叢集參數之後回收應用程式連線。