# Aurora MySQL 线程状态 以下是 Aurora MySQL 的一些常见的线程状态。 **检查权限** 线程正在检查服务器是否具有运行语句所需的权限。 **检查查询缓存以进行查询** 服务器正在检查查询缓存中是否存在当前查询。 **已清除** 这是连接的最终状态，其工作已完成但客户端尚未关闭。最好的解决方案是在代码中明确关闭连接。或者您可以在参数组中设置较低的 `wait_timeout` 值。 **关闭表** 线程正在将更改后的表数据刷新到磁盘并关闭使用过的表。如果这不是快速操作，请根据实例类网络带宽验证网络带宽消耗指标。另外，请检查 `table_open_cache` 和 `table_definition_cache` 参数的参数值是否允许同时打开足够的表，以使引擎不需要频繁地打开和关闭表。这些参数会影响实例的内存消耗。 **将 HEAP 转换为 MyISAM** 该查询正在将临时表从内存中的表转换为磁盘上的表。这种转换是必要的，因为 MySQL 在查询处理的中间步骤中创建的临时表对内存来说太大了。检查 `tmp_table_size` 和 `max_heap_table_size` 的值。在更高版本中，此线程状态名称为 `converting HEAP to ondisk`。 **将 HEAT 转换为磁盘上** 线程正在将内部临时表从内存中的表转换为磁盘上的表。 **复制到 tmp 表** 线程正在处理 `ALTER TABLE` 语句。此状态发生在具有新结构的表创建之后，但在将行复制到该表中之前。对于处于此状态的线程，您可以使用性能架构获取有关复制操作进度的信息。 **创建排序索引** Aurora MySQL 正在执行一种排序，因为它不能使用现有的索引来满足查询的 `ORDER BY` 或 `GROUP BY` 子句。有关更多信息，请参阅 [创建排序索引](ams-states.sort-index.md)。 **创建表** 该线程正在创建一个永久表或临时表。 **延迟提交确定完成** Aurora MySQL 中的异步提交已收到确认并已完成。 **延迟提交确定启动** Aurora MySQL 线程已启动异步提交过程，但正在等待确认。这通常是事务的真正提交时间。 **延迟发送确定完成** 在向客户端发送响应时，可以释放绑定到连接的 Aurora MySQL 工作线程。线程可以开始其他工作。状态 `delayed send ok` 意味着对客户端的异步确认已完成。 **延迟发送确定已启动** Aurora MySQL 工作线程已异步向客户端发送响应，现在可以自由地为其他连接工作。事务已启动一个尚未确认的异步提交过程。 **executing** 线程已经开始运行语句。 **释放项目** 线程已运行命令。在此状态下完成的一些项目释放涉及到查询缓存。这种状态之后通常是清理。 **init** 此状态发生在 `ALTER TABLE`、`DELETE`、`INSERT`、`SELECT` 或者 `UPDATE` 语句的初始化之前。处于此状态的操作包括刷新二进制日志或 InnoDB 日志，以及清理查询缓存。 **源已将所有二进制日志发送给副本；正在等待更多更新** 主节点已完成其复制的一部分。线程正在等待更多查询运行，以便可以写入二进制日志 (binlog)。 **打开表** 线程正在尝试打开一张表。除非 `ALTER TABLE` 或者 `LOCK TABLE` 语句需要完成，或者它超出了 `table_open_cache` 的值，否则此操作会快速完成。 **正在优化** 服务器正在对查询执行初始优化。 **正在准备** 在查询优化期间会出现此状态。 **查询结束** 此状态发生在处理查询之后但在释放项目状态之前。 **删除重复项** Aurora MySQL 无法在查询的早期阶段优化 `DISTINCT` 操作。Aurora MySQL 必须先删除所有重复的行，然后才能将结果发送给客户端。 **搜索行以进行更新** 在更新它们之前，线程会查找所有匹配的行。如果 `UPDATE` 正在更改引擎用来查找行的索引，这个阶段有必要。 **向从节点发送二进制日志事件** 线程从二进制日志中读取事件并将其发送到副本。 **向客户端发送缓存的结果** 服务器正在从查询缓存中获取查询的结果并将其发送到客户端。 **发送数据** 线程正在读取和处理 `SELECT` 语句的行，但尚未开始向客户端发送数据。该过程是确定哪些页面包含满足查询所需的结果。有关更多信息，请参阅 [发送数据](ams-states.sending-data.md)。 **发送给客户端** 服务器正在向客户端写入数据包。在早期的 MySQL 版本中，此等待事件被标记为 `writing to net`。 **starting** 这是语句执行开始的第一阶段。 **statistics** 服务器正在计算统计数据以制定查询执行计划。如果线程长期处于此状态，则在执行其他工作时，服务器可能会绑定磁盘。 **将结果存储在查询缓存中** 服务器正在将查询结果存储在查询缓存中。 **系统锁定** 线程已调用 `mysql_lock_tables`，但是自调用以来，线程状态尚未更新。出现这种普遍状态的原因很多。 **更新** 线程正在准备开始更新表格。 **更新** 线程正在搜索行并更新它们。 **用户锁定** 该线程发出 `GET_LOCK` 调用。该线程在请求一个咨询锁并在等待该锁，或者计划请求咨询锁。 **等待更多更新** 主节点已完成其复制的一部分。线程正在等待更多查询运行，以便可以写入二进制日志 (binlog)。 **等待架构元数据锁定** 这是等待元数据锁定。 **等待存储的函数元数据锁定** 这是等待元数据锁定。 **等待存储的过程元数据锁定** 这是等待元数据锁定。 **等待表刷新** 线程正在执行 `FLUSH TABLES` 并且正在等待所有线程关闭他们的表。或者线程收到通知，指示表格的底层结构发生了变化，因此它必须重新打开表格以获得新结构。要重新打开表格，线程必须等到所有其他线程都关闭表格。如果另一个线程使用了表格上的以下语句之一，则会发出此通知：`FLUSH TABLES`、`ALTER TABLE`、`RENAME TABLE`、`REPAIR TABLE`、`ANALYZE TABLE` 或 `OPTIMIZE TABLE`。 **等待表级锁定** 一个会话在表上保持锁定，而另一个会话则试图在同一个表上获取同一个锁定。 **等待表元数据锁定** Aurora MySQL 使用元数据锁定来管理对数据库对象的并发访问并确保数据一致性。在此等待事件中，一个会话在表上保持元数据锁定，而另一个会话则试图在同一个表上获取同一个锁定。启用性能架构后，此线程状态将报告为等待事件 `synch/cond/sql/MDL_context::COND_wait_status`。 **写入网络** 服务器正在向网络写入数据包。在以后的 MySQL 版本中，此等待事件被标记为 `Sending to client`。