本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 監控 Aurora MySQL 的平行查詢 如果您的 Aurora MySQL 叢集使用平行查詢，您可能會看到 `VolumeReadIOPS` 值增加。平行查詢不會使用緩衝集區。因此，雖然查詢速度很快，但這種最佳化處理可能會導致讀取操作和相關費用增加。 除了[在 Amazon RDS 主控台中檢視指標](USER_Monitoring.md)中描述的 Amazon CloudWatch 指標之外，Aurora 還會提供其他全域狀態變數。您可以使用這些全域狀態變數來協助監視平行查詢執行。它們可以讓您深入了解為什麼最佳化程式可能在指定的情況下使用或不使用平行查詢。若要存取這些變數，您可以使用 `[SHOW GLOBAL STATUS](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html)` 命令。您也可以尋找這些列示在下面的變數。 平行查詢工作階段與資料庫所執行的查詢不一定是一對一映射。例如，假設您的執行計劃中有兩個步驟會用到平行查詢。在此情況下，查詢涉及兩個平行工作階段，而且嘗試請求和成功請求的計數器都會增加 2。 當您發出 `EXPLAIN`陳述式試驟平行查詢時，預期看到指定為「未選擇」的計數器增加，即使查詢實際上並未執行也一樣。在生產中使用平行查詢時，您可以檢查「未選擇」計數器的增加速度是否超過您預期的速度。在這點上，您可以調整，讓平行查詢執行您預期的查詢。若要執行這項操作，您可以變更叢集設定、查詢混合、開啟平行查詢的資料庫執行個體等。 這些計數器是在資料庫執行個體層級進行追蹤。當您連線至不同端點時，可能看到不同指標，因為每個資料庫執行個體都執行自己的一組平行查詢。當讀取器端點連線至每個工作階段的不同資料庫執行個體時，您也可能看到不同指標。 | 名稱 | 描述 | | --- | --- | | `Aurora_pq_bytes_returned` | 在平行查詢期間已傳輸至前端節點之 Tuple 資料結構的位元組數目。除以 16,384 以針對 `Aurora_pq_pages_pushed_down` 進行比較。 | | `Aurora_pq_max_concurrent_requests` | 可以同時在此 Aurora 資料庫執行個體上執行之平行查詢工作階段的數目上限。這是取決於 AWS 資料庫執行個體類別的固定數目。 | | `Aurora_pq_pages_pushed_down` | 資料頁面的數目 (每個頁面的固定大小為 16 KiB)，在這些資料頁面中平行查詢已避免透過網路將資料傳輸至前端節點。 | | `Aurora_pq_request_attempted` | 已請求的平行查詢工作階段數目。此值可能代表每個查詢多個工作階段，取決於 SQL 建構，例如子查詢和聯結。 | | `Aurora_pq_request_executed` | 已成功執行的平行查詢工作階段數目。 | | `Aurora_pq_request_failed` | 已傳回錯誤至用戶端的平行查詢工作階段數目。在某些情況下，平行查詢的請求可能失敗，例如，因為儲存層中發生問題。在這些情況下，會使用非平行查詢機制來重試失敗的查詢部分。如果重試的查詢也失敗，則錯誤會傳回至用戶端，而且此計數器會遞增。 | | `Aurora_pq_request_in_progress` | 目前進行中的平行查詢工作階段數目。此數目適用於您已連線的特定 Aurora 資料庫執行個體，但不適用於整個 Aurora 資料庫叢集。若要查看資料庫執行個體是否接近並行限制，請將此值與 `Aurora_pq_max_concurrent_requests` 比較。 | | `Aurora_pq_request_not_chosen` | 未選擇平行查詢以滿足查詢的次數。此值是數個其他更精細計數器的總和。`EXPLAIN` 陳述式可以增加此計數器，即使查詢實際上並未執行。 | | `Aurora_pq_request_not_chosen_below_min_rows` | 由於資料表中的資料列數而未選擇平行查詢的次數。`EXPLAIN` 陳述式可以增加此計數器，即使查詢實際上並未執行。 | | `Aurora_pq_request_not_chosen_column_bit` | 使用非平行查詢處理路徑，因為投影的資料欄清單中不支援的資料類型的平行查詢要求數目。 | | `Aurora_pq_request_not_chosen_column_geometry` | 因為 `GEOMETRY` 資料表具有資料類型的資料行，所以使用非平行查詢處理路徑的平行查詢要求數目。如需移除此限制之 Aurora MySQL 版本的相關資訊，請參閱[將平行查詢叢集升級至 Aurora MySQL 第 3 版](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2)。 | | `Aurora_pq_request_not_chosen_column_lob` | 使用非平行查詢處理路徑的平行查詢要求數目，因為資料表具有 `LOB` 資料類型的 `VARCHAR` 資料欄，或因宣告長度而儲存在外部的資料欄。如需移除此限制之 Aurora MySQL 版本的相關資訊，請參閱[將平行查詢叢集升級至 Aurora MySQL 第 3 版](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2)。 | | `Aurora_pq_request_not_chosen_column_virtual` | 因為資料表包含虛擬資料欄，所以會使用非平行查詢處理路徑的平行查詢要求數目。 | | `Aurora_pq_request_not_chosen_custom_charset` | 因為資料表具有自訂字元集的資料欄，所以會使用非平行查詢處理路徑的平行查詢要求數目。 | | `Aurora_pq_request_not_chosen_fast_ddl` | 使用非平行查詢處理路徑的平行查詢要求數目，因為資料表目前正在變更快速的 DDL `ALTER` 陳述式。 | | `Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool` | 即使小於 95% 的資料表資料在緩衝集區中，也未選擇平行查詢的次數，因為沒有足夠的未置於緩衝的資料表資料，讓平行查詢值得執行。 | | `Aurora_pq_request_not_chosen_full_text_index` | 因為資料表具有全文檢索索引，所以會使用非平行查詢處理路徑的平行查詢要求數目。 | | `Aurora_pq_request_not_chosen_high_buffer_pool_pct` | 因為高百分比的資料表資料 (目前，大於 95%) 已在緩衝集區中，所以未選擇平行查詢的次數。在這些情況下，最佳化器判定從緩衝集區讀取資料最有效率。`EXPLAIN` 陳述式可以增加此計數器，即使查詢實際上並未執行。 | | `Aurora_pq_request_not_chosen_index_hint` | 因為查詢包含索引提示，所以會使用非平行查詢處理路徑的平行查詢要求數目。 | | `Aurora_pq_request_not_chosen_innodb_table_format` | 因為資料表使用不支援的 InnoDB 資料列格式，所以會使用非平行查詢處理路徑的平行查詢要求數目。Aurora 平行查詢只適用於 `COMPACT`、`REDUNDANT` 和 `DYNAMIC` 資料列格式。 | | `Aurora_pq_request_not_chosen_long_trx` | 由於在長時間執行的交易內啟動查詢，而使用非平行查詢處理路徑的平行查詢請求數目。`EXPLAIN` 陳述式可以增加此計數器，即使查詢實際上並未執行。 | | `Aurora_pq_request_not_chosen_no_where_clause` | 因為查詢不包含任何 `WHERE` 子句，所以會使用非平行查詢處理路徑的平行查詢要求數目。 | | `Aurora_pq_request_not_chosen_range_scan` | 因為查詢在索引上使用範圍掃描，所以會使用非平行查詢處理路徑的平行查詢要求數目。 | | `Aurora_pq_request_not_chosen_row_length_too_long` | 因為所有資料欄的總合長度太長，所以會使用非平行查詢處理路徑的平行查詢要求數目。 | | `Aurora_pq_request_not_chosen_small_table` | 由於資料表中的整體大小 (由資料列數和平均資料列長度決定) 而未選擇平行查詢的次數。`EXPLAIN` 陳述式可以增加此計數器，即使查詢實際上並未執行。 | | `Aurora_pq_request_not_chosen_temporary_table` | 因為查詢參考使用不支援 `MyISAM` 或 `memory` 資料表類型的暫存資料表，所以會使用非平行查詢處理路徑的平行查詢要求數目。 | | `Aurora_pq_request_not_chosen_tx_isolation` | 因為查詢使用不支援的交易隔離層級，所以會使用非平行查詢處理路徑的平行查詢要求數目。在讀取器資料庫執行個體上，平行查詢僅適用於 `REPEATABLE READ` 和 `READ COMMITTED` 隔離層級。 | | `Aurora_pq_request_not_chosen_update_delete_stmts` | 因為查詢是 `UPDATE` 或 `DELETE` 陳述式的一部分，所以會使用非平行查詢處理路徑的平行查詢要求數目。 | | `Aurora_pq_request_not_chosen_unsupported_access` | 因為 `WHERE` 子句不符合平行查詢的條件，所以使用非平行查詢處理路徑的平行查詢請求數目。如果查詢不需要資料密集掃描，或如果查詢是 `DELETE` 或 `UPDATE` 陳述式，則會發生此結果。 | | `Aurora_pq_request_not_chosen_unsupported_storage_type` | 由於 Aurora MySQL 資料庫叢集未使用支援的 Aurora 叢集儲存組態，因此平行查詢數目請求是使用非平行查詢處理路徑。此參數適用於 Aurora MySQL 3.04 版及更新版本。如需更多詳細資訊，請參閱 [限制](aurora-mysql-parallel-query.md#aurora-mysql-parallel-query-limitations)。 | | `Aurora_pq_request_throttled` | 由於已在特定 Aurora 資料庫執行個體上執行的並行平行查詢數目已達到上限，而未選擇平行查詢的次數。 |