After create：当线程创建一个表完成时（包括内部临时表），会出现这种状态。
即使由于某些错误而导致创建表最终出错，也会出现此状态
Analyzing：线程正在 ANALYZE TABLE
checking permissions：正在 server 中检查线程是否具有执行语句所需的权限
Checking table：线程正在执行表检查操作
cleaning up：线程已经执行完成了一个命令，并准备释放所占用的内存和重置某些状态变量
closing tables：线程正在将表发生更改的数据刷新到磁盘并关闭表。
converting HEAP to MyISAM：线程正在将内部临时表从 MEMORY 引擎表转换为磁盘 MyISAM 引擎的临时表
copy to tmp table：线程正在执行 ALTER TABLE 语句。此状态发生在新结构的表已经创建好之后，执行 copy 旧表数据到新表中之前出现
Copying to group table：如果语句使用了不同的 ORDER BY 和 GROUP BY 条件列，则按照 group by 对这些行数据进行排序，并将排序结果复制到临时表
Copying to tmp table：server 正在复制数据到内存临时表
altering table：server 正在执行 in-place 的 ALTER TABLE 的过程
Copying to tmp table on disk：server 正在复制数据到磁盘临时表。因为临时结果集太大，所以，线程正在将内存临时表转换为基于磁盘的临时表，以节省内存
Creating index：线程正在执行一个 ALTER TABLE … ENABLE KEYS 语句
Creating sort index：线程正在执行 SELECT 且使用到了内部临时表
creating table：线程正在创建表。包括创建临时表时也会使用此状态
Creating tmp table：线程正在内存或磁盘上创建一个临时表。如果表在内存中创建，但后来被转换为磁盘表，则该操作期间的状态将为“Copying to tmp table on disk”
committing alter table to storage engine：server 已执行完成 in-place 算法的 ALTER TABLE 语句，正在提交
deleting from main table：server 正在执行多表删除语句中的第一部分。看到这个
状态表示正在从第一个表中删除，并保存后续用于删除其他表的列数据和偏移量
deleting from reference tables：server 正在执行多表删除语句的第二部分，从其他表中删除匹配的行
discard_or_import_tablespace ：线程正在执行 ALTER TABLE … DISCARD TABLESPACE 或 ALTER TABLE … IMPORT TABLESPACE 语句
end：这发生在语句执行结束时，但在清除 ALTER TABLE，CREATE VIEW，DELETE，INSERT，SELECT 或 UPDATE 语句之前出现该状态
executing：线程正在执行语句中
Execution of init_command：线程正在执行一个初始化系统变量的语句
freeing items：线程已经执行完成了一个命令。释放一些涉及到 query cache 状态
的 items。这种状态后通常紧随 cleaning up 状态之后
FULLTEXT initialization：server 正在准备执行自然语言全文搜索
init：这在 ALTER TABLE，DELETE，INSERT，SELECT 或 UPDATE 语句初始化之前发生的状态。server 在此状态下执行的操作包括刷新二进制日志，InnoDB 日志和一些查询缓存清理操作。对于这个状态结束时，可能会有如下一些操作：
当表中的数据更改后删除查询缓存条目
将事件写入二进制日志
释放内存缓冲区，包括 blob
Killed：向线程发起一个 kill 操作，线程应该执行终止操作。在 MySQL 的每个主循环中检查线程的 kill 标志，但在某些情况下，杀死线程可能只需要很短的时间。但如果被 kill 的线程被其他线程锁定，则需要等待其他线程释放锁之后，kill 命令才会生效并执行。
logging slow query：线程正在向慢查询日志写一条语句
login：连接线程的初始状态，直到客户端成功通过身份验证
manage keys：server 正在启用或禁用表索引
NULL：此状态用于 SHOW PROCESSLIST 语句
Opening tables：线程正尝试打开一个表。打开表操作应该非常快，除非打开操作被阻止。例如，ALTER TABLE 或 LOCK TABLE 语句可以防止打开表，直到该语句完成。另外也可能是 table_open_cache 不够大导致不能打开表。
optimizing：server 正在对查询执行初始优化
preparing：此状态发生在查询优化期间
Purging old relay logs：线程正在删除不需要的中继日志文件
query end：此状态出现在执行查询语句之后但在释放该查询语句相关状态 items 之前
Reading from net：server 正在从网络读取数据包。在 MySQL 5.7.8 之后该状态叫做“Receiving from client” - Receiving from client：server 正在从客户端读取数据包。在 MySQL 5.7.8 叫做“Reading from net”
Removing duplicates：查询使用 SELECT DISTINCT 语句时，使 MySQL 无法在早期阶段优化掉 distinct 操作。因此，MySQL 需要一个额外的阶段来删除所有重复的行，然后将结果发送到客户端
removing tmp table：线程在 SELECT 语句执行完成后，正在删除内部临时表。如果 SELECT 语句未创建临时表，则不会出现此状态
rename：线程正在执行 rename 语句重命名表
rename result table：线程正在执行 ALTER TABLE 语句重命名表，已经创建完成新表，并正在使用新表替换旧表名称
Reopen tables：线程获得了表锁，但是获得锁后，发现基础表结构已经被改变了。
于是释放表锁，并关闭表，尝试重新打开表
Repair by sorting：修复代码正在使用排序来创建索引
preparing for alter table：server 正在准备执行 in-place 算法的 ALTER TABLE 语 句 - Repair done：该线程已完成 MyISAM 表的多线程修复
Repair with keycache：修复代码正在使用通过 key cache 逐个创建 key 的方法修复索引。这比通过排序索引修复的方法慢得多
Rolling back：线程正在回滚事务
Saving state：对于 MyISAM 表操作（如修复或分析），线程正在将新表状态保存到.MYI 文件头。状态包括：表数据行数,AUTO_INCREMENT 计数器和 key
分布之类的信息
Searching rows for update：线程正在进行第一阶段查找所有匹配的行，然后再更新它们。如果 UPDATE 正在更改用于查找涉及的行的索引，则必须先把 update 满足匹配的行先查找出来
Sending data：线程正在读取和处理 SELECT 语句产生的数据行，并将数据发送到客户端。因为在此状态期间发生的操作可能产生大量的磁盘访问（读取），所以它通常是给定查询的生存期内最长的运行状态
Sending to client：server 正在向客户端写入数据包。在 MySQL 5.7.8 之前叫做“Writing to net”
setup：线程正在执行 ALTER TABLE 操作
Sorting for group：线程正在执行一个 GROUP BY 排序操作
Sorting for order：线程正在执行一个 ORDER BY 排序操作
Sorting index：线程正在排序索引页面，以便在 MyISAM 表优化操作期间实现更高效的访问
Sorting result：对于 SELECT 语句，这类似“Creating sort index”状态，但是针对于非临时表
statistics：server 正在计算统计信息以优化查询执行计划。如果一个线程在这个状态很长一段时间，server 可能是磁盘执行其他工作而阻塞了统计信息的操作，也有可能发生了锁等待。
System lock：线程调用了mysql_lock_tables()，线程状态从未更新过。这是一个非常常见的状态，出现该状态的原因有很多。例如，线程将请求或正在等待表的内部或外部系统锁定。当 InnoDB 在执行 LOCK TABLES 期间等待表级锁时，可能会发生这种情况。如果此状态是由外部锁请求引起的，如果您不使用多个mysqld 服务器访问同一 MyISAM 表，则可以使用–skip-external-locking 选项禁用外部系统锁。但是，默认情况下外部锁定是禁用的，因此此选项可能无效。
对于 SHOW PROFILE，此状态表示线程正在请求锁定
update：线程准备开始更新表
Updating：线程搜索且正在更新数据行
updating main table：server 正在执行多表更新语句的第一部分。该状态表示正在
更新第一个表，并保存列值和偏移量以用于更新其他（引用）表
updating reference tables：server 正在执行多表更新语句的第二部分，更新其他表
的匹配行
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：线程获取到一个通知，表的底层结构已经改变，它需要重新打开表以获得新的结构。但是，要重新打开表，它必须等待，直到所有其他线
程都关闭了旧数据结构的表的访问。如果另一个线程已在表中使用 FLUSH TABLES 或下列语句之一，则就会出现这个通知：
感谢你能够认真阅读完这篇文章，希望小编分享的“MySQL线程状态的示例分析”这篇文章对大家有帮助，同时也希望大家多多支持天达云，关注天达云行业资讯频道，更多相关知识等着你来学习!