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

# 正在傳送資料
<a name="ams-states.sending-data"></a>

`sending data` 執行緒狀態表示執行緒正在讀取和篩選查詢的資料列，以決定正確的結果集。名稱產生誤導，因為它暗示狀態正在傳輸資料，而不是收集和準備稍後傳送的資料。

**Topics**
+ [支援的引擎版本](#ams-states.sending-data.context.supported)
+ [Context](#ams-states.sending-data.context)
+ [等待變多的可能原因](#ams-states.sending-data.causes)
+ [動作](#ams-states.sending-data.actions)

## 支援的引擎版本
<a name="ams-states.sending-data.context.supported"></a>

下列版本支援這個執行緒狀態資訊：
+ Aurora MySQL 第 2 版，最高至 2.09.2

## Context
<a name="ams-states.sending-data.context"></a>

許多執行緒狀態是短暫的。`sending data` 期間發生的作業傾向於執行大量磁碟或快取讀取。因此，`sending data` 通常是執行時間最長的狀態，涵蓋給定查詢的生命週期。當 Aurora MySQL 執行下列動作時，此狀態便會出現：
+ 讀取和處理 `SELECT` 陳述式的資料列
+ 從磁碟或記憶體執行大量讀取
+ 從特定查詢中完成所有資料的完整讀取
+ 從資料表、索引或預存程序的工作中讀取資料
+ 排序、分組或排序資料

在 `sending data` 狀態完成準備資料之後，執行緒狀態 `writing to net` 指出資料傳回至用戶端。通常，只在結果集非常大或嚴重的網路延遲正在減慢傳輸速度時，才會擷取 `writing to net`。

## 等待變多的可能原因
<a name="ams-states.sending-data.causes"></a>

出現 `sending data` 本身並不表示有問題。如果效能不佳，並且您經常看到 `sending data` 的執行個體，最可能的原因如下。

**Topics**
+ [無效率查詢](#ams-states.sending-data.causes.structure)
+ [次佳伺服器組態](#ams-states.sending-data.causes.server)

### 無效率查詢
<a name="ams-states.sending-data.causes.structure"></a>

在大多數情況下，應對此狀態負責的是未使用適當的索引來尋找特定查詢之結果集的查詢。例如，考慮一個查詢，其為加州所有訂單讀取 1,000 萬筆記錄資料表，其中狀態資料行未建立索引或未好好建立索引。在後者情況下，索引可能存在，但最佳化工具由於低基數而忽略它。

### 次佳伺服器組態
<a name="ams-states.sending-data.causes.server"></a>

如果數個查詢出現在 `sending data` 狀態中，則可能未好好設定資料庫伺服器。尤其，伺服器可能有下列問題：
+ 資料庫伺服器沒有足夠的運算容量：磁碟輸入/輸出、磁碟類型和速度、CPU 或 CPU 數量。
+ 伺服器缺乏配置的資源，例如 InnoDB 資料表的 InnoDB 緩衝集區或 MyISAM 資料表的索引鍵緩衝區。
+ 每個執行緒記憶體設定 (例如 `sort_buffer`、`read_buffer` 和 `join_buffer`) 都會耗用比所需還要多的 RAM，因而使實體伺服器缺乏記憶體資源。

## 動作
<a name="ams-states.sending-data.actions"></a>

一般指導方針是檢查效能結構描述來尋找傳回大量資料列的查詢。如果不使用索引的記錄查詢已開啟，您也可以檢查來自慢速日誌的結果。

**Topics**
+ [如果未開啟效能結構描述，請將其開啟](#ams-states.sending-data.actions.enable-pfs)
+ [檢查記憶體設定](#ams-states.sending-data.actions.memory)
+ [檢查說明計劃以取得索引使用情形](#ams-states.sending-data.actions.plans)
+ [檢查傳回的資料量](#ams-states.sending-data.actions.maintenance)
+ [檢查是否有並行問題](#ams-states.sending-data.actions.concurrent-queries)
+ [檢查請求的結構](#ams-states.sending-data.actions.subqueries)

### 如果未開啟效能結構描述，請將其開啟
<a name="ams-states.sending-data.actions.enable-pfs"></a>

只在效能結構描述檢測未開啟時，績效詳情才會報告執行緒狀態。當效能結構描述檢測開啟時，績效詳情會改為報告等待事件。效能結構描述檢測會在您調查潛在的效能問題時提供其他洞察和更好的工具。因此，建議您開啟效能結構描述。如需詳細資訊，請參閱[Aurora MySQL 上 Performance Insights 的效能結構描述概觀](USER_PerfInsights.EnableMySQL.md)。

### 檢查記憶體設定
<a name="ams-states.sending-data.actions.memory"></a>

檢查主要緩衝集區的記憶體設定。確定這些集區已適當地調整為適合工作負載的大小。如果您的資料庫使用多個緩衝集區執行個體，請確定它們不會分成許多小型緩衝集區。資料表一次只能使用一個緩衝集區。

請確定下列用於每個執行緒的記憶體設定，其大小適當：
+ read\_buffer
+ read\_rnd\_buffer
+ sort\_buffer
+ join\_buffer
+ binlog\_cache

除非您有修改設定的特定原因，否則請使用預設值。

### 檢查說明計劃以取得索引使用情形
<a name="ams-states.sending-data.actions.plans"></a>

對於處於 `sending data` 執行緒狀態的查詢，請檢查計劃，以判斷是否使用適當的索引。如果查詢未使用有用的索引，請考慮新增 `USE INDEX` 或 `FORCE INDEX` 之類的提示。提示可大幅增加或減少執行查詢所需的時間，因此在新增它們之前請小心。

### 檢查傳回的資料量
<a name="ams-states.sending-data.actions.maintenance"></a>

檢查正在查詢的資料表，以及它們包含的資料量。可以封存此資料的任何一個嗎？ 在許多情況下，查詢執行時間不佳的原因不是查詢計劃的結果，而是要處理的資料量。許多開發人員在將資料新增到資料庫時非常有效率，但在設計和開發階段很少考慮資料集生命週期。

尋找在低容量資料庫中表現良好，但在目前系統中表現不佳的查詢。有時設計特定查詢的開發人員可能無法意識到這些查詢正在傳回 350,000 個資料列。開發人員可能已在較低容量環境 (其具有的資料集比生產環境具有的還要小) 開發了查詢。

### 檢查是否有並行問題
<a name="ams-states.sending-data.actions.concurrent-queries"></a>

檢查相同類型的多個查詢是否同時執行。某些形式的查詢在單獨執行時可以有效地執行。不過，如果類似形式的查詢一起執行或大量執行，它們可能會導致並發問題。通常，當資料庫使用暫時資料表來呈現結果時，就會造成這些問題。限制性交易隔離層級也可能會導致並行問題。

如果同時讀取和寫入至資料表，則資料庫可能正在使用鎖定。若要協助識別效能不佳的期間，請透過大規模的批次程序檢查資料庫的使用情形。若要查看最近的鎖定和回復，請檢查 `SHOW ENGINE INNODB STATUS` 命令的輸出。

### 檢查請求的結構
<a name="ams-states.sending-data.actions.subqueries"></a>

檢查從這些狀態擷取的查詢是否使用子查詢。這種類型的查詢通常會導致效能不佳，因為資料庫會在內部編譯結果，然後將它們代入查詢以呈現資料。此程序是資料庫的額外步驟。在許多情況下，這個步驟可能會在高度並行載入條件中造成不佳的效能。

亦請檢查您的查詢是否使用大量的 `ORDER BY` 和 `GROUP BY` 子句。在這類操作中，通常資料庫必須首先在記憶體中形成整個資料集。然後，必須在將其傳送至用戶端之前以特定方式將其排序或分組。