以下列表描述了与常规查询处理相关的线程 State
值,而不是与复制等更专业的活动相关的线程状态值。其中许多值仅用于查找服务器中的错误。
当线程创建表(包括内部临时表)时,在创建表的函数结束时会出现这种情况。即使由于某些错误无法创建表,也会使用此状态。
服务器正在执行就地
ALTER TABLE
。线程正在计算
MyISAM
表键分布(例如,用于ANALYZE TABLE
)。线程正在检查服务器是否具有执行该语句所需的权限。
线程正在执行表检查操作。
线程已处理一个命令,并准备释放内存并重置某些状态变量。
线程正在将更改的表数据刷新到磁盘并关闭使用的表。这应该是一个快速的操作。如果不是,请验证您的磁盘空间是否已满,以及磁盘使用率是否过高。
committing alter table to storage engine
服务器已完成就地
ALTER TABLE
,并且正在提交结果。线程正在将内部临时表从
MEMORY
表转换为磁盘表。线程正在处理
ALTER TABLE
语句。此状态发生在创建具有新结构的表之后,但在将行复制到该表之前。对于处于此状态的线程,可以使用性能模式来获取有关复制操作进度的信息。请参阅 第 29.12.5 节,“性能模式阶段事件表”。
如果语句具有不同的
ORDER BY
和GROUP BY
条件,则会按组对行进行排序,并将其复制到临时表。服务器正在复制到内存中的临时表。
服务器正在复制到磁盘上的临时表。临时结果集已变得太大(请参阅 第 10.4.4 节,“MySQL 中的内部临时表使用”)。因此,线程正在将临时表从内存中格式更改为基于磁盘的格式,以节省内存。
线程正在为
MyISAM
表处理ALTER TABLE ... ENABLE KEYS
。线程正在处理使用内部临时表解析的
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
语句,并且它应该在下一次检查终止标志时中止。该标志在 MySQL 的每个主循环中都会检查,但在某些情况下,线程可能仍需要一点时间才能终止。如果线程被其他线程锁定,则终止将在其他线程释放其锁后立即生效。线程正在尝试锁定系统表(例如,时区表或日志表)。
线程正在将语句写入慢查询日志。
连接线程的初始状态,直到客户端成功通过身份验证。
服务器正在启用或禁用表索引。
线程正在尝试打开系统表(例如,时区表或日志表)。
线程正在尝试打开表。这应该是一个非常快的过程,除非有什么阻止打开。例如,
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
期间等待表级锁时,可能会发生这种情况。 如果此状态是由外部锁请求引起的,并且您没有使用多个访问同一个MyISAM
表的 mysqld 服务器,则可以使用--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 节“性能模式锁表” 中描述的性能模式锁表。
线程正在等待条件变为真的通用状态。 没有特定的状态信息可用。
服务器正在将数据包写入网络。