以下列表描述了与通用查询处理相关的线程 State
值,而不是专门用于复制等特殊活动的值。许多这些值仅用于在服务器中查找错误。
-
这发生在线程创建表(包括内部临时表)时,在创建表的函数结束时。这状态用于即使表无法创建也会出现错误。
-
服务器正在执行就地
ALTER TABLE
。 -
线程正在计算
MyISAM
表键分布(例如,用于ANALYZE TABLE
)。 -
线程正在检查服务器是否具有执行语句所需的权限。
-
线程正在执行表检查操作。
-
线程已经处理了一个命令,并正在释放内存并重置某些状态变量。
-
线程正在将更改的表数据刷新到磁盘并关闭使用的表。这应该是一个快速操作。如果不是,请验证您没有磁盘空间不足的问题,并且磁盘不在非常繁忙的情况下。
-
committing alter table to storage engine
服务器已经完成了就地
ALTER TABLE
,并正在提交结果。 -
线程正在将内部临时表从
MEMORY
表转换为磁盘表。 -
线程正在处理
ALTER TABLE
语句。这状态发生在创建了具有新结构的表之后,但是在将行复制到其中之前。对于处于该状态的线程,Performance Schema 可以用于获取关于复制操作的进度信息。请参阅 第 29.12.5 节,“Performance Schema 阶段事件表”。
-
如果语句具有不同的
ORDER BY
和GROUP BY
条件,则行将根据组排序并复制到临时表中。 -
服务器正在将数据复制到内存中的临时表中。
-
服务器正在将数据复制到磁盘上的临时表中。临时结果集变得太大(请参阅 第 10.4.4 节,“MySQL 中的内部临时表使用”)。因此,线程正在将临时表从内存中更改为基于磁盘的格式以节省内存。
-
线程正在处理
ALTER TABLE ... ENABLE KEYS
语句用于MyISAM
表。 -
线程正在处理一个使用内部临时表解析的
SELECT
。 -
线程正在创建一个表。这包括创建临时表。
-
线程正在创建一个内存或磁盘上的临时表。如果表是在内存中创建的,但后来被转换为磁盘上的表,那么在该操作期间的状态是
将临时表复制到磁盘
。 -
服务器正在执行多表删除的第一部分。它只从第一个表中删除,并保存列和偏移量,以便从其他(引用)表中删除。
-
服务器正在执行多表删除的第二部分,并从其他表中删除匹配的行。
-
线程正在处理
ALTER TABLE ... DISCARD TABLESPACE
或ALTER TABLE ... IMPORT TABLESPACE
语句。 -
这发生在
ALTER TABLE
、CREATE VIEW
、DELETE
、INSERT
、SELECT
或UPDATE
语句之前的清理之前。对于
结束
状态,可能正在发生以下操作:-
将事件写入二进制日志
-
释放内存缓冲区,包括 blob
-
-
线程已经开始执行语句。
-
线程正在执行
init_command
系统变量的值中的语句。 -
线程已经执行了命令。这通常跟随着
清理
。 -
服务器正在准备执行自然语言全文搜索。
-
这发生在
ALTER TABLE
、DELETE
、INSERT
、SELECT
或UPDATE
语句之前的初始化中。服务器在这个状态下执行的操作包括刷新二进制日志和 InnoDB 日志。 -
有人向线程发送了
KILL
语句,它应该在下一次检查 kill 标志时中止。如果线程被其他线程锁定,那么 kill 将在其他线程释放锁时生效。 -
线程正在尝试锁定系统表(例如时间区表或日志表)。
-
线程正在将语句写入慢查询日志。
-
连接线程的初始状态,直到客户端成功身份验证。
-
服务器正在启用或禁用表索引。
-
线程正在尝试打开系统表(例如时间区表或日志表)。
-
线程正在尝试打开表。这应该是一个非常快速的过程,除非某些事情阻止了打开。例如,
ALTER TABLE
或LOCK TABLE
语句可以阻止打开表,直到语句完成。它也值得检查您的table_open_cache
值是否足够大。对于系统表,使用
打开系统表
状态代替。 -
服务器正在执行查询的初始优化。
-
该状态发生在查询优化期间。
-
服务器正在准备执行就地
ALTER TABLE
。 -
线程正在删除不需要的中继日志文件。
-
该状态发生在处理查询后,但是在
释放项目
状态之前。 -
服务器正在从客户端读取数据包。
-
查询使用
SELECT DISTINCT
,以至于 MySQL 无法在早期阶段优化掉 distinct 操作。因此,MySQL 需要额外的阶段来删除重复行,然后将结果发送给客户端。 -
线程正在删除内部临时表,处理
SELECT
语句后。如果没有创建临时表,则不使用该状态。 -
线程正在重命名表。
-
线程正在处理
ALTER TABLE
语句,已经创建了新表,并正在将其重命名以替换原始表。 -
线程获取了表锁,但是在获取锁后发现了表结构的变化。它释放了锁,关闭了表,并正在尝试重新打开它。
-
修复代码使用排序创建索引。
-
线程已经完成了多线程修复
MyISAM
表。 -
修复代码使用键缓存逐个创建键。这比
通过排序修复
慢得多。 -
线程正在回滚事务。
-
对于
MyISAM
表操作,如修复或分析,线程正在将新表状态保存到.MYI
文件头中。状态包括行数、AUTO_INCREMENT
计数器和键分布信息。 -
线程正在执行第一阶段,以找到所有匹配的行,然后更新它们。这必须在
UPDATE
更改用于查找涉及行的索引时执行。 -
发送数据
现在,这个状态已包含在
执行
状态中。 -
服务器正在将数据包写入客户端。
-
线程正在开始
ALTER TABLE
操作。 -
线程正在执行排序,以满足
GROUP BY
。 -
线程正在执行排序,以满足
ORDER BY
。 -
线程正在对索引页进行排序,以便在
MyISAM
表优化操作期间更高效地访问。 -
对于
SELECT
语句,这与创建排序索引
相似,但用于非临时表。 -
语句执行的第一阶段。
-
服务器正在计算统计信息,以开发查询执行计划。如果线程长时间处于此状态,服务器可能正在执行其他磁盘绑定工作。
-
线程已经调用了
mysql_lock_tables()
,并且线程状态自那时以来没有更新。这是一个非常通用的状态,可以由于许多原因而发生。例如,线程正在请求或等待内部或外部系统锁定表。这可能发生在
InnoDB
等待表级锁定期间执行LOCK TABLES
。如果这是由于外部锁定请求引起的,并且您不使用多个 mysqld 服务器访问同一个MyISAM
表,您可以使用--skip-external-locking
选项禁用外部系统锁定。但是,外部锁定默认情况下是禁用的,因此该选项可能无效。对于SHOW PROFILE
,这意味着线程正在请求锁定(而不是等待锁定)。对于系统表,该状态将使用
Locking system tables
。 -
线程正在准备开始更新表。
-
线程正在搜索要更新的行并更新它们。
-
服务器正在执行多表更新的第一部分。它仅更新第一个表,并保存列和偏移量以供更新其他(引用)表。
-
服务器正在执行多表更新的第二部分,并更新其他表中的匹配行。
-
线程正在请求或等待使用
GET_LOCK()
调用请求的咨询锁定。对于SHOW PROFILE
,这意味着线程正在请求锁定(而不是等待锁定)。 -
线程已经调用了
SLEEP()
。 -
FLUSH TABLES WITH READ LOCK
正在等待提交锁定。 -
线程正在等待事务提交与查询处理的其他部分。
-
线程收到了表结构更改的通知,需要重新打开表以获取新结构。但是,为了重新打开表,需要等待所有其他线程关闭该表。
这发生在另一个线程使用
FLUSH TABLES
或以下语句之一在该表上时:FLUSH TABLES
、tbl_name
ALTER TABLE
、RENAME TABLE
、REPAIR TABLE
、ANALYZE TABLE
或OPTIMIZE TABLE
。 -
线程正在执行
FLUSH TABLES
,并等待所有线程关闭它们的表,或者线程收到了表结构更改的通知,需要重新打开表以获取新结构。但是,要重新打开表,必须等待所有其他线程关闭该表。这种通知发生在另一个线程对该表执行了
FLUSH TABLES
或以下语句之一:FLUSH TABLES
、tbl_name
ALTER TABLE
、RENAME TABLE
、REPAIR TABLE
、ANALYZE TABLE
或OPTIMIZE TABLE
。 -
服务器正在等待获取
THR_LOCK
锁或元数据锁定子系统中的锁,其中lock_type
表示锁的类型。该状态表示等待获取
THR_LOCK
:-
等待表级锁
这些状态表示等待元数据锁:
-
等待事件元数据锁
-
等待全局读锁
-
等待模式元数据锁
-
等待存储函数元数据锁
-
等待存储过程元数据锁
-
等待表元数据锁
-
等待触发器元数据锁
有关表锁指示符的信息,请参阅 第 10.11.1 节,“内部锁定方法”。有关元数据锁定的信息,请参阅 第 10.11.4 节,“元数据锁定”。要查看哪些锁阻止锁请求,请使用性能架构锁表,如 第 29.12.13 节,“性能架构锁表” 中所述。
-
-
一个通用状态,其中线程正在等待某个条件变为真。没有特定的状态信息可用。
-
服务器正在将数据包写入网络。