Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

发送数据

sending data 线程状态表示线程正在读取和筛选查询的行以确定正确的结果集。这个名称具有误导性，因为它意味着该状态为正在传输数据，而不是收集和准备以后发送的数据。

支持的引擎版本

以下版本支持此线程状态信息：

上下文

许多线程状态都是短期的。sending data 期间发生的操作倾向于执行大量磁盘或缓存读取。因此，sending data 通常是在给定查询生命周期内运行时间最长的状态。当 Aurora MySQL 执行以下操作时会出现此状态：

当 sending data 状态完成准备数据后，线程状态 writing to net 表示向客户端返回数据。通常，仅当结果集非常大或严重的网络延迟正在减慢传输速度时才捕获 writing to net。

等待次数增加的可能原因

sending data 的外观本身并不表明存在问题。如果性能不佳，且您看到频繁 sending data 实例，最可能的原因如下所示。

低效的查询

在大多数情况下，造成此状态的原因是查询没有使用适当的索引来查找特定查询的结果集。例如，考虑查询读取在加利福尼亚州下的所有订单的 1000 万条记录表，其中的状态列没有索引或索引不良。在后一种情况下，索引可能存在，但由于基数较低，优化器忽略了它。

不理想的服务器配置

如果多个查询显示在 sending data 状态，数据库服务器可能配置不佳。具体来说，服务器可能存在以下问题：

操作

一般指南是通过检查性能架构来查找返回大量行的查询。如果启用了不使用索引的记录查询，您还可以检查慢日志的结果。

如果性能架构未开启，请打开它

仅在性能架构工具未打开时，性能详情才会报告线程状态。启用性能架构工具后，性能详情会报告等待事件。在调查潜在的性能问题时，性能架构工具可以提供更多洞察和更好的工具。因此，建议您开启性能架构。有关更多信息，请参阅 为 Aurora MySQL 上的 Performance Insights 启用 Performance Schema。

检查内存设置

检查主缓冲池的内存设置。确保这些缓冲池的大小适合工作负载。如果您的数据库使用多个缓冲池实例，请确保它们没有被划分为许多小型缓冲池。线程一次只能使用一个缓冲池。

确保用于每个线程的以下内存设置的大小正确：

除非您有特定原因要修改设置，否则请使用原定设置值。

检查索引使用的解释计划

对于 sending data 线程状态中的查询，检查计划以确定是否使用了适当的索引。如果查询没有使用有用的索引，请考虑添加 USE INDEX 或 FORCE INDEX 之类的提示。提示可以大大增加或减少运行查询所需的时间，因此在添加提示之前请小心。

检查返回的数据量

检查正在查询的表以及它们包含的数据量。这些数据都可以存档吗？ 在许多情况下，查询执行时间不佳的原因不是查询计划的结果，而是要处理的数据量。许多开发人员可以非常有效地向数据库添加数据，但在设计和开发阶段，很少会考虑数据集生命周期。

查找在低容量数据库中表现良好但在当前系统中表现不佳的查询。有时，设计特定查询的开发人员可能没有意识到这些查询返回了 350000 行。开发人员可能是在数据集小于生产环境数据集的较小容量环境中开发了查询。

检查并发问题

检查是否同时运行同一类型的多个查询。有些形式的查询在单独运行时会有效运行。但是，如果类似形式的查询一起运行，或者运行量大，它们可能会导致并发问题。通常，这些问题是在数据库使用临时表渲染结果时引起的。限制性事务隔离级别也可能导致并发问题。

如果同时读取和写入表，则数据库可能正在使用锁定。为了帮助确定性能不佳的时期，请通过大规模批处理过程来检查数据库的使用情况。要查看最近的锁定和回滚，请检查 SHOW ENGINE INNODB STATUS 命令的输出。

检查您的查询结构

检查从这些状态捕获的查询是否使用子查询。这种类型的查询通常会导致性能不佳，因为数据库会在内部编译结果，然后将其替换回查询中以渲染数据。这个过程是数据库的额外步骤。在许多情况下，在高度并发的加载条件下，此步骤可能会导致性能不佳。

同时，检查您的查询是否使用了大量 ORDER BY 和 GROUP BY 子句。在此类操作中，数据库通常必须首先在内存中形成整个数据集。然后，它必须以特定的方式对数据集进行排序或分组，然后才能将其返回给客户端。