# データの送信
<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`ステートメント
+ ディスクまたはメモリから大量の読み取りを実行する
+ 特定のクエリからのすべてのデータの完全な読み取りを完了する
+ テーブル、インデックス、またはストアドプロシージャの作業からデータを読み込む
+ データのソート、グループ化、または順序付け

After`sending data`state はデータの準備を終了し、スレッドの状態`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`状態の場合、データベースサーバーの設定が不十分である可能性があります。具体的には、サーバーには次の問題が発生する可能性があります。
+ データベースサーバーには、ディスク I/O、ディスクタイプと速度、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>

Performance Insights は、パフォーマンススキーマインストゥルメントがオンになっていない場合にのみ、スレッドの状態を報告します。パフォーマンススキーマインストゥルメントがオンの場合、Performance Insights は代わりに待機イベントをレポートします。パフォーマンススキーマインストゥルメントは、潜在的なパフォーマンスの問題を調査するための、追加のインサイトと優れたツールを提供します。したがって、パフォーマンススキーマをオンにすることをお勧めします。詳細については、「[Aurora MySQL における Performance Insights のPerformance Schema の概要](USER_PerfInsights.EnableMySQL.md)」を参照してください。

### メモリ設定の確認
<a name="ams-states.sending-data.actions.memory"></a>

プライマリバッファプールのメモリ設定を確認します。これらのプールがワークロードに合わせて適切なサイズになっていることを確認します。データベースで複数のバッファプールインスタンスを使用している場合は、それらが多数の小さなバッファプールに分割されていないことを確認してください。スレッドが一度に使用できるバッファプールは 1 つだけです。

各スレッドで使用される次のメモリ設定が、適切なサイズであることを確認します。
+ read\$1buffer
+ read\$1rnd\$1buffer
+ sort\$1buffer
+ join\$1buffer
+ binlog\$1cache

設定を変更する特定の理由がない限り、デフォルト値を使用します。

### インデックスの使用状況に関する説明プランを調べる
<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`句 をクエリが使用していないかも、確認してください。このような操作では、多くの場合、データベースはまずデータセット全体をメモリ内に形成する必要があります。その後、クライアントに戻す前に、特定の方法で注文またはグループ化する必要があります。