【MySQL】线程状态详解

前言:我们常用 show processlistshow full processlist 查看数据库连接状态,其中比较关注的是 State 列,此列表示该连接此刻所在的状态。那么你真的了解不同 State 值所表示的状态吗?下面我们参考官方文档来一探究竟 。

以MySQL 5.7版本为例

官方文档地址:https://dev.mysql.com/doc/refman/5.7/en/general-thread-states.html

简单翻译下:

  • After create

    当线程在创建表的函数末尾创建表(包括内部临时表)时,会发生这种情况。即使由于某些错误而无法创建表,也会使用此状态。

  • Analyzing

    线程正在计算MyISAM表键分布(例如,for ANALYZE TABLE)。

  • checking permissions

    线程正在检查服务器是否具有执行语句所需的权限。

  • Checking table

    该线程正在执行表检查操作。

  • cleaning up

    该线程已经处理了一个命令,并准备释放内存并重置某些状态变量。

  • closing tables

    该线程正在将更改的表数据刷新到磁盘并关闭已使用的表。这应该是一个快速的操作。如果没有,请验证您的磁盘空间剩余。

  • converting HEAP to ondisk

    该线程正在将内部临时表从 MEMORY表转换为磁盘表。

  • copy to tmp table

    线程正在处理一个ALTER TABLE语句。在创建具有新结构的表但在将行复制到其中之前,将发生此状态。

    对于处于此状态的线程,可以使用性能模式来获取有关复制操作的进度。

  • Copying to group table

    如果语句具有不同的条件ORDER BYGROUP BY标准,则按组对行进行排序并将其复制到临时表。

  • Copying to tmp table

    服务器正在复制到内存中的临时表。

  • altering table

    服务器正在执行就地 ALTER TABLE

  • Copying to tmp table on disk

    服务器正在复制到磁盘上的临时表。

  • Creating index

    线程正在处理ALTER TABLE ... ENABLE KEYS一个MyISAM表。

  • Creating sort index

    线程正在处理SELECT使用内部临时表解析的线程 。

  • creating table

    线程正在创建一个表。这包括创建临时表。

  • Creating tmp table

    该线程正在内存或磁盘上创建临时表。如果表在内存中创建但稍后转换为磁盘表,则该操作期间的状态将为Copying to tmp table on disk

  • committing alter table to storage engine

    服务器已完成就地 ALTER TABLE并提交结果。

  • deleting from main table

    服务器正在执行多表删除的第一部分。它仅从第一个表中删除,并保存用于从其他(引用)表中删除的列和偏移量。

  • deleting from reference tables

    服务器正在执行多表删除的第二部分,并从其他表中删除匹配的行。

  • discard_or_import_tablespace

    线程正在处理ALTER TABLE ... DISCARD TABLESPACEALTER TABLE ... IMPORT TABLESPACE声明。

  • end

    这发生在结束,但的清理之前 ALTER TABLECREATE VIEWDELETEINSERTSELECT,或 UPDATE语句。

  • executing

    该线程已开始执行语句。

  • Execution of init_command

    线程正在执行init_command系统变量值中的语句 。

  • freeing items

    线程执行了一个命令。在此状态期间完成的一些项目的释放涉及查询缓存。这种状态通常紧随其后cleaning up

  • FULLTEXT initialization

    服务器正准备执行自然语言全文搜索。

  • init

    出现这种情况的初始化之前 ALTER TABLEDELETEINSERTSELECT,或 UPDATE语句。服务器在此状态下采取的操作包括刷新二进制日志,InnoDB日志和一些查询缓存清理操作。

    对于end状态,可能会发生以下操作:

    • 删除表中的数据后删除查询缓存条目
    • 将事件写入二进制日志
    • 释放内存缓冲区,包括blob
  • Killed

    有人KILL 向线程发送了一个语句,它应该在下次检查kill标志时中止。在MySQL的每个主循环中检查该标志,但在某些情况下,线程可能仍然需要很短的时间才能死掉。如果线程被某个其他线程锁定,则一旦另一个线程释放其锁定,kill就会生效。

  • logging slow query

    该线程正在向慢查询日志写一条语句。

  • login

    连接线程的初始状态,直到客户端成功通过身份验证。

  • manage keys

    服务器正在启用或禁用表索引。

  • NULL

    该状态用于该SHOW PROCESSLIST状态。

  • Opening tables

    线程正在尝试打开一个表。这应该是非常快的程序,除非有什么东西阻止打开。例如,一个ALTER TABLE或一个 LOCK TABLE语句可以阻止在语句结束之前打开表。

  • optimizing

    服务器正在对查询执行初始优化。

  • preparing

    在查询优化期间发生此状态。

  • Purging old relay logs

    该线程正在删除不需要的中继日志文件。

  • query end

    处理查询后但在freeing items状态之前发生此 状态。

  • Receiving from client

    服务器正在从客户端读取数据包。Reading from net在MySQL 5.7.8之前调用此状态。

  • Removing duplicates

    该查询使用 SELECT DISTINCT的方式是MySQL无法在早期阶段优化掉不同的操作。因此,在将结果发送到客户端之前,MySQL需要额外的阶段来删除所有重复的行。

  • removing tmp table

    该线程在处理SELECT 语句后删除内部临时表。如果未创建临时表,则不使用此状态。

  • rename

    该线程正在重命名一个表。

  • rename result table

    线程正在处理一个ALTER TABLE语句,创建了新表,并重命名它以替换原始表。

  • Reopen tables

    该线程获得了表的锁定,但在获取锁定之后注意到基础表结构发生了变化。它释放了锁,关闭了桌子,并试图重新打开它。

  • Repair by sorting

    修复代码使用排序来创建索引。

  • preparing for alter table

    服务器正准备执行就地 ALTER TABLE

  • Repair done

    该线程已完成对MyISAM表的多线程修复 。

  • Repair with keycache

    修复代码通过密钥缓存逐个创建密钥。这比慢得多Repair by sorting

  • Rolling back

    该线程正在回滚一个事务。

  • Saving state

    对于MyISAM诸如修复或分析的表操作,线程将新表状态保存到.MYI文件头。状态包括诸如行数, AUTO_INCREMENT计数器和密钥分发之类的信息。

  • Searching rows for update

    该线程正在进行第一阶段以在更新之前查找所有匹配的行。如果 UPDATE要更改用于查找所涉及行的索引,则必须执行此操作。

  • Sending data

    线程正在读取和处理SELECT语句的行 ,并将数据发送到客户端。由于在此状态期间发生的操作往往会执行大量磁盘访问(读取),因此它通常是给定查询生命周期中运行时间最长的状态。

  • Sending to client

    服务器正在向客户端写入数据包。Writing to net在MySQL 5.7.8之前调用此状态。

  • setup

    线程正在开始一个ALTER TABLE操作。

  • Sorting for group

    线程正在进行排序以满足 GROUP BY

  • Sorting for order

    线程正在进行排序以满足ORDER BY

  • Sorting index

    该线程正在对索引页面进行排序,以便在MyISAM表优化操作期间进行更有效的访

  • Sorting result

    对于SELECT声明,这类似于Creating sort index非临时表。

  • statistics

    服务器正在计算统计信息以开发查询执行计划。如果线程长时间处于此状态,则服务器可能是磁盘绑定执行其他工作。

  • System lock

    线程已经调用 mysql_lock_tables() ,并且线程状态尚未更新。这是一个非常普遍的状态,可能由于多种原因而发生。

    例如,线程将请求或正在等待表的内部或外部系统锁定。InnoDB在执行期间等待表级锁定时会 发生这种情况LOCK TABLES。如果此状态是由外部锁的请求引起的,并且您没有使用多个访问相同 表的mysqld服务器,则MyISAM可以使用该--skip-external-locking 选项禁用外部系统锁 。但是,默认情况下禁用外部锁定,因此该选项很可能无效。对于 SHOW PROFILE,这个状态意味着线程正在请求锁定(不等待它)。

  • update

    线程正准备开始更新表。

  • Updating

    线程正在搜索要更新的行并正在更新它们。

  • updating main table

    服务器正在执行多表更新的第一部分。它仅更新第一个表,并保存用于更新其他(引用)表的列和偏移量。

  • updating reference tables

    服务器正在执行多表更新的第二部分,并更新其他表中的匹配行。

  • User lock

    该线程将要求或正在等待通过GET_LOCK()呼叫请求的咨询锁 。对于 SHOW PROFILE,此状态表示线程正在请求锁定(不等待它)。

  • User sleep

    线程已经调用了一个 SLEEP()调用。

  • Waiting for commit lock

    FLUSH TABLES WITH READ LOCK 正在等待提交锁定。

  • Waiting for global read lock

    FLUSH TABLES WITH READ LOCK 正在等待全局读锁定或read_only正在设置全局 系统变量。

  • Waiting for tables

    线程得到一个通知,表明表的底层结构已经改变,它需要重新打开表以获得新结构。但是,要重新打开表,它必须等到所有其他线程关闭了相关表。

  • Waiting for table flush

    线程正在执行FLUSH TABLES并且正在等待所有线程关闭它们的表,或者线程得到一个表的基础结构已经更改的通知,并且它需要重新打开表以获取新结构。但是,要重新打开表,它必须等到所有其他线程关闭了相关表。

  • Waiting for *lock_type* lock

    服务器正在等待THR_LOCK从元数据锁定子系统获取 锁定或锁定,其中 lock_type指示锁定的类型。

    此状态表示等待 THR_LOCK

    • Waiting for table level lock

    这些状态表示等待元数据锁定:

    • Waiting for event metadata lock
    • Waiting for global read lock
    • Waiting for schema metadata lock
    • Waiting for stored function metadata lock
    • Waiting for stored procedure metadata lock
    • Waiting for table metadata lock
    • Waiting for trigger metadata lock
  • Waiting on cond

    线程正在等待条件变为真的通用状态。没有具体的州信息。

  • Writing to net

    服务器正在将数据包写入网络。Sending to client从MySQL 5.7.8开始调用此状态。

关于 Command 列的含义可以参考:https://dev.mysql.com/doc/refman/5.7/en/thread-commands.html

原文地址:https://blog.51cto.com/10814168/2355861

时间: 2024-10-09 15:13:18

【MySQL】线程状态详解的相关文章

MySQL线程状态详解

前言: 我们常用 show processlist 或 show full processlist 查看数据库连接状态,其中比较关注的是 State 列,此列表示该连接此刻所在的状态.那么你真的了解不同 State 值所表示的状态吗?下面我们参考官方文档来一探究竟 . 以MySQL 5.7版本为例 官方文档地址: https://dev.mysql.com/doc/refman/5.7/en/general-thread-states.html 简单翻译下: After create 当线程在创

Java性能分析之线程栈详解(下)

Java性能分析之线程栈详解(下) 转载自:微信公众号"测试那点事儿" 结合jstack结果对线程状态详解 上篇文章详细介绍了线程栈的作用.状态.任何查看理解,本篇文章结合jstack工具来查看线程状态,并列出重点关注目标.Jstack是常用的排查工具,它能输出在某一个时间,Java进程中所有线程的状态,很多时候这些状态信息能给我们的排查工作带来有用的线索. Jstack的输出中,Java线程状态主要是以下几种: 1.BLOCKED 线程在等待monitor锁(synchronized

MySQL主从架构详解

1.复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置.从服务器接收

Mysql 配置参数详解以及优化配置

mysql有以下几种日志: 错误日志:   log-err 查询日志:   log 慢查询日志:  log-slow-queries 更新日志:   log-update 二进制日志: log-bin 要把日志生成在 /var/log 目录下(是系统日志存放的地方,只有 root 账号有写权限),需要 MySQL进程对这个目录有读写权限,一般是不这么做的,也考虑到安全问题,包括 MySQL 本身的数据安全,因为对 MySQL 的所有操作,都会记录到常规查询日志.MySQL的日志就不要用 /var

(转)MySQL备份原理详解

MySQL备份原理详解 原文:http://www.cnblogs.com/cchust/p/5452557.html 备份是数据安全的最后一道防线,对于任何数据丢失的场景,备份虽然不一定能恢复百分之百的数据(取决于备份周期),但至少能将损失降到最低.衡量备份恢复有两个重要的指标:恢复点目标(RPO)和恢复时间目标(RTO),前者重点关注能恢复到什么程度,而后者则重点关注恢复需要多长时间.这篇文章主要讨论MySQL的备份方案,重点介绍几种备份方式的原理,包括文件系统快照(LVM),逻辑备份工具M

MySQL数据库备份详解

原文:MySQL数据库备份详解 对于任何数据库来说,备份都是非常重要的 数据库复制不能取代备份的作用 比如我们由于误操作,在主数据库上删除了一些数据,由于主从复制的时间很短,在发现时,从数据库上的数据可能也已经被删除了, 我们不能使用从数据库上的数据来恢复主数据库上的数据,只能通过备份进行误删除数据的恢复 一. 备份的分类 1.按备份的结果来分: 逻辑备份 其备份结果为SQL语句,适合于所有存储引擎,恢复时需要较多时间,逻辑备份时,对于MyISAM存储引擎是需要进行锁表操作的,通过使用的mysq

Mysql 三大特性详解

Mysql 三大特性详解 Mysql Innodb后台线程 工作方式 首先Mysql进程模型是单进程多线程的.所以我们通过ps查找mysqld进程是只有一个. 体系架构 InnoDB存储引擎的架构如下图所以,是由多个内存块组成的内存池,同时又多个后台线程进行工作,文件是存储磁盘上的数据. 后台线程 上面看到一共有四种后台线程,每种线程都在不停地做自己的工作,他们的分工如下: Master Thread: 是最核心的线程,主要负责将缓冲池中的数据异步刷新的磁盘,保证数据的一致性,包括脏页的刷新.合

MySQL配置文件mysql.ini参数详解、MySQL性能优化

MySQL配置文件mysql.ini参数详解.MySQL性能优化 my.ini(Linux系统下是my.cnf),当mysql服务器启动时它会读取这个文件,设置相关的运行环境参数. my.ini分为两块:Client Section和Server Section.   Client Section用来配置MySQL客户端参数.   要查看配置参数可以用下面的命令: show variables like '%innodb%'; # 查看innodb相关配置参数 show status like

[转]iOS应用程序生命周期(前后台切换,应用的各种状态)详解

转载地址:http://blog.csdn.net/totogo2010/article/details/8048652 iOS的应用程序的生命周期,还有程序是运行在前台还是后台,应用程序各个状态的变换,这些对于开发者来说都是很重要的. iOS系统的资源是有限的,应用程序在前台和在后台的状态是不一样的.在后台时,程序会受到系统的很多限制,这样可以提高电池的使用和用户体验. //开发app,我们要遵循apple公司的一些指导原则,原则如下: 1.应用程序的状态 状态如下: Not running