Original source: MySQL 5.5 Reference Manual
Part of the translation: "mysql_5.1 Chinese reference Manual"
Reprint please specify the original link http://www.cnblogs.com/lenagt/archive/2012/06/06/2538201.html Thank you.
Status entries in Show Processlist output: 5.1 None of the manuals, or the translation of the problem, are accompanied by 5.5 original description:
This occurs when the thread creates a table (including internal temporary tables) in the end of the function that creates The table. This was used even if the table could not being created due to some error.
This state occurs when a thread creates a table (including an internal temporary table) at the end of the build table feature. This state is used even if some errors result in a failure to build the table.
The thread is calculating a MyISAM table key distributions (for example, for ANALYZE table).
When you calculate the MyISAM table index distribution. (e.g. when analyze table is performed)
The thread is checking whether the server have the required privileges to execute the statement.
This thread checks to see if the server has the required permissions to execute the statement.
The thread is performing a table check operation.
The thread is performing a table check operation.
The thread has processed one command and are preparing to free memory and reset certain state variables.
The thread processes a command and is preparing to free memory and reset certain state variables.
The thread is flushing the changed table data to disk and closing the used tables. This should is a fast operation. If not, verify-do not has a full disk and that the disk was not in very heavy use.
The thread is flushing data from the changed table to disk and is shutting down the used table. This should be a quick operation. If not, you should check if the hard disk space is full or if the hard disk IO reaches the bottleneck.
Converting HEAP to MyISAM
The thread is converting an internal temporary table from a MEMORY table to an on-disk MyISAM table.
The thread converts an internal temporary table to a MyISAM table on disk.
Copy to TMP table
The thread is processing an ALTER TABLE statement. The occurs after the table with the new structure have been created but before rows is copied into it.
The line is impersonating is processing an ALTER TABLE statement. This state occurs after the new table structure has been created, but before the data is copied into it.
Copying to Group table
If A statement have different ORDER by and group by criteria, the rows is sorted by GROUP and copied to a temporary table.
If a statement has different order by and group by conditions, the data is copied to a temporary table and sorted by group.
Copying to TMP table
The server is copying to a temporary table in memory.
The thread writes data to a temporary table in memory.
Copying to TMP table on disk
The server is copying-a temporary table on disk. The temporary result set has a become too large (see sections 18.104.22.168, "How MySQL Uses Internal temporary Tables"). Consequently, the thread is changing the temporary table from in-memory to diskbased format to save memory.
The thread is writing data to a temporary table in disk. The result set of the staging table is too large (greater than tmp_table_size). Therefore, the thread changes the temp table from memory-based mode to disk-based mode to save memory.
The thread is processing ALTER TABLE ... ENABLE KEYS for a MyISAM table.
The thread is executing an ALTER TABLE on a MyISAM table ... The ENABLE keys statement.
Creating Sort Index
The thread is processing a SELECT, is resolved using a internal temporary table.
The thread is using an internal temporary table to process a select operation.
The thread is creating a table. This includes creation of temporary tables.
A thread is creating a table, including creating a temporary table.
Creating tmp table
The thread is creating a temporary table in memory or on disk. If The table is created in memory but later are converted to a Ondisk table, the state during that operation would be copyi NG to TMP table on disk.
The thread is creating a temporary table in memory or on disk. If the table is created in memory but then converted to disk, this state is maintained when the copying to TMP table is running on disk.
deleting from Main Table
The server is executing the first part of a multiple-table delete. It is deleting only from the first table, and saving columns and offsets to being used for deleting from the other (reference ) tables.
The thread is performing the first part of a multi-table delete and is only removed from the first table. and save columns and offsets to remove from other (reference) tables.
deleting from reference tables
The server is executing the second part of a multiple-table deletes and deleting the matched rows from the other tables.
The thread is performing the second part of the multi-table delete and removes the matching rows from the other tables.
The thread is processing an ALTER TABLE ... DISCARD tablespace or ALTER TABLE ... IMPORT tablespace statement.
The thread is executing alter TABLE ... DISCARD tablespace or ALTER TABLE ... IMPORT tablespace statement.
This occurs at the end but before the cleanup of ALTER TABLE, CREATE VIEW, DELETE, INSERT, SELECT, or UPDATE statements.
This state occurs at the end, but before the alter TABLE, CREATE VIEW, DELETE, INSERT, SELECT, or UPDATE statement is cleaned up.
The thread has begun executing a statement.
The thread has started executing a statement.
Execution of Init_command
The thread is executing statements in the value of the Init_command system variable.
The thread is executing the statement in the value of the Init_command system variable.
The thread has executed a command. Some freeing of items do during this state involves the query cache. This was usually followed by cleaning up.
The thread has executed the command. The query cache involved in this state can get some release. This state usually follows the cleaning up state.
The thread is executing FLUSH TABLES and are waiting for all threads to close their TABLES.
The thread is executing flush TABLES and waits for all threads to close their tables.
The server is preparing to perform a natural-language full-text search.
The server is preparing for a natural language full-text search.
This occurs before the initialization of ALTER TABLE, DELETE, INSERT, SELECT, or UPDATE statements. Actions taken by the server in this state include flushing the binary log, the InnoDB log, and some query Cache cleanup op Erations.
For the end state, the following operations could is happening:
removing query cache entries after data in a table is changed
writing an event to the binary log
freeing memory buffers, including for BLOBs
This state occurs before the thread initializes the alter TABLE, DELETE, INSERT, SELECT, or UPDATE statement. The operations performed by the server in this state include: refreshing the full-time log, InnoDB logs, and some query cache cleanup operations.
For the end state, the following actions may occur:
Removes the query cache after data changes in the table.
Writes a transaction to a full-time log.
Frees the memory buffers, including large binary data blocks.
Someone have sent a kill statement to the thread and it should abort next time it checks the kill flag. The flag is checked with major loop in MySQL, and in some cases it might still take a short time for the thread to die. If the thread is locked by some and other thread, the kill takes effect as soon as the other thread releases its lock.
The program sends a KILL statement to the thread, and it should discard the next check on the kill tag. This tag is checked in every MySQL main loop, but in some cases it may need to cause the thread to die in a short period of time. If the thread is locked by another thread, the kill operation releases the instantaneous execution of the lock on the other thread.
The query is locked by another query.
As of MySQL 5.5.3, this state was removed because it is equivalent to the Table lock state and no longer appears in SHOW Processlist output.
This query has been locked by another query.
In MySQL version 5.5.3, this state was removed. Because it is equivalent to the table lock state and no longer appears in the show processlist output.
Logging Slow Query
The thread is writing a statement to the Slow-query log.
This thread is writing a statement to the slow query log.
This was used for the SHOW processlist state.
There is no operational status.
The initial state for a connection thread until the client has been authenticated successfully.
The initial state of the thread connection. Until the client has successfully verified.
The server is enabling or disabling a table index.
The server enables or disables table indexing.
Opening Tables, Opening table
The thread is trying to open a table. This was should be very fast procedure, unless something prevents opening. For example, an ALTER TABLE or a LOCK table statement can prevent opening a table until the statement is finished. It is also worth checking this your Table_open_cache value is large enough.
Line is impersonating tries to open a table. This should be a very fast process unless the opening is blocked. An ALTER TABLE or LOCK TABLE statement prevents the opening of a table until the statement runs to the end. It is necessary to check whether the value of the Table_open_cache is large enough.
The server is performing initial optimizations for a query.
The server performs a preliminary optimization of the query.
This state occurs during query optimization.
This state occurs during the query optimization process.
Purging Old relay logs
The thread is removing unneeded relay log files.
The thread is removing unnecessary trunk log files.
This state occurs after processing a query but before the freeing items state.
This state occurs after a query is processed, but before the freeing items state.
Reading from net
The server is reading a packet from the network.
The server is reading the packet from the network.
The query was using SELECT DISTINCT in such a-a-in-a-could not optimize away the DISTINCT-operation at a early St Age. Because of this, MySQL requires a extra stage to remove all duplicated rows before sending the result to the client.
The query is using select DISTINCT, in which case MySQL cannot optimize some DISTINCT operations in the early stages. Therefore, MySQL requires an additional stage to delete all duplicate rows before sending the results to the client.
removing TMP table
The thread is removing an internal temporary table after processing a SELECT statement. The used if no temporary table was created.
The thread is removing a built-in temporary table after executing a SELECT statement. If no temporary table is generated, then this state is not used.
The thread is renaming a table.
The thread is renaming a table.
Rename result table
The thread is processing an ALTER table statement, have created the new table, and is renaming it to replace the original T Able.
The line is impersonating handles the ALTER TABLE statement, creates a new table, and renames it to replace the original table.
The thread got a lock for the table, but noticed after getting the lock, the underlying table structure changed. It has freed the lock, closed the table, and was trying to reopen it.
The thread obtains a table lock, but the underlying structure of the table has changed since the table lock was obtained. The thread releases this lock, closes the table, and tries to reopen the table.
Repair by sorting
The repair code is using a sort to create indexes.
The repair code is using a taxonomy to create the index.
The thread has completed a multi-threaded repair for a MyISAM table.
The thread completes the repair of a multi-threaded MyISAM table.
Repair with Keycache
The repair code is a using creating keys one by one through the key cache. This was much slower than Repair by sorting.
The fix code is using the index cache one by one to create the index. This is much slower than sorting through a fix.
The thread is rolling back a transaction.
Thread is rolling back a transaction
For MyISAM table operations such as repair or analysis, the thread was saving the new table state to the. MYI file header. State includes information such as number of rows, the auto_increment counter, and key distributions.
For similar repair or analysis operations on MyISAM tables, the thread is in. The Myi file's head holds the state of a new table. State information includes the number of rows, the number of self-increment, the index distribution, and so on.
Searching rows for update
The thread is doing a first phase to find all matching rows before updating them. This have to was done if the UPDATE is changing the index, the used to find the involved rows.
The thread is in the first phase, looking for all matching rows before the update. If update is changing the index used to find related rows, you must do so.
The thread is reading and processing rows for a SELECT statement, and sending data to the client. Because operations occurring during this this state tend to perform large amounts of disk access (reads), it is often the Longest-running state over the lifetime of a given query.
The thread is reading and processing a row of a SELECT statement and sends the data to the client. Because of the large amount of disk access (read operations) During this period, this state is often the longest in the life cycle of a specified query.
The thread is beginning an ALTER TABLE operation.
The thread is starting an ALTER TABLE operation.
Sorting for group
The thread is doing a sort to satisfy a GROUP by.
The thread is performing a sort specified by the group by.
Sorting for order
The thread is doing a sort to satisfy a ORDER by.
The thread is performing a sort specified by an order by.
The thread is sorting index pages for more efficient access during a MyISAM table optimization operation.
The thread is sorting the index pages for better performance in order to operate on the MyISAM table.
For a SELECT statement, this is similar to Creating sort index, but for nontemporary tables.
For a SELECT statement, this is similar to creating a sort index, but to a non-temporal table.
The server is calculating statistics to develop a query execution plan. If a thread is a and a long time, the server is probably Disk-bound performing.
The server calculates the statistics to plan a query. If a thread is in this state for a long time, the server's disk may be performing other work.
The thread is going to request or was waiting for a internal or external system lock for the table. If This state is a being caused by requests for external locks and you were not using multiple MYSQLD servers it is access ing the same MyISAM tables, you can disable External system locks with the--skip-external-locking option. However, external locking is disabled by default, so it's likely that this option would have no effect. For SHOW profiles, this state means the thread is requesting the lock
(not waiting for it).
This thread is requesting or waiting for an internal or external system table lock. If this status is due to an external lock request and you are not using multiple MYSQLD servers that are accessing the same table, then you can disable the external System lock using the--skip-external-locking option. However, external system locks are disabled by default, so this option may not produce an effect. For show profile, this state means that the thread is requesting a lock. (rather than waiting)
The next thread state is after System lock. The thread has acquired a external lock and is going to request an internal table lock.
This is replaced in MySQL 5.5.6 with waiting for table level lock.
The next thread state after the system is locked. The thread has acquired an external lock and will request an internal table lock.
This status is replaced by waiting for table level lock in MySQL version 5.5.6.
The thread is searching for rows to update and is updating them.
The thread looks for updates to match the rows and updates.
Updating Main Table
The server is executing the first part of a multiple-table update. It is updating only the first table, and saving columns and offsets to being used for updating the other (reference) tables.
The thread is performing the first part of a multi-table update and is only updated from the first table. and save columns and offsets to update from other (reference) tables.
Updating reference tables
The server is executing the second part of a multiple-table update and updating the matched rows from the other tables.
The thread is performing the second part of the Multi-table update, and the matching rows are updated from the other tables.
The thread is going to request or was waiting for a advisory lock requested with a Get_lock () call. For SHOW profiles, this state means the thread was requesting the lock (not waiting for it).
The thread is requesting or waiting for a get_lock () call to request the requested consultation lock. For show profile, this state means that the thread is requesting a lock. (rather than waiting)
The thread has invoked a SLEEP () call.
The thread called a sleep ().
Waiting for all running commits to finish
A statement that causes an explicit or implicit commits is waiting for release of a read lock. This is removed in MySQL 5.5.8; Waiting for commit lock is used instead.
An explicit or implicit statement waits for a read lock to be released when committed. This state was removed in MySQL version 5.5.8 and replaced with waiting for commit lock.
Waiting for Commit lock
A statement that causes an explicit or implicit commit was waiting for release of a read lock or FLUSH TABLES with read LOC K) is waiting for a commit lock. This is added in MySQL 5.5.8.
Ibid., this status is added to MySQL version 5.5.8.
Waiting for global read lock
FLUSH TABLES with read lock) are waiting for a global READ lock.
Waits for a global read lock.
Waiting for release of Readlock
The thread is waiting-a global read lock obtained by another thread (with FLUSH TABLES with read lock) to be released. This is removed in MySQL 5.5.8; Waiting for global read lock or waiting for commit lock is used instead.
Wait for the read lock to be released.
Waiting for tables, waiting for table, waiting for table flush
The thread got a notification that the underlying structure for a table have changed and it needs to reopen the table to GE t the new structure. However, to reopen the table, it must wait until all other threads has closed the table in question.
This notification takes place if another thread have used FLUSH TABLES or one of the following statements on the table in Q Uestion:flush TABLES tbl_name, ALTER table, RENAME table, REPAIR table, ANALYZE table, or OPTIMIZE table.
In MySQL 5.5.6, the waiting for table is replaced with the waiting for table flush.
The thread gets a notification that the underlying table structure has changed, and it needs to reopen the table to get the new structure. However, to reopen the table, it must wait until all other threads close the problematic table.
This notification usually occurs because another thread executes flush TABLES or one of the following statements on the problem table: Flush TABLES tbl_name, ALTER table, RENAME table, REPAIR table, ANALYZE table, or OPTIMIZE table.
The server is waiting to acquire a lock, where lock_type indicates the type of lock:
Waiting for event metadata lock (added in MySQL 5.5.8)
waiting for global metadata lock (replaced by waiting for global read lock in MySQL 5.5.8)
waiting for Global read lock (added in MySQL 5.5.8)
waiting for schema metadata lock
waiting for stored function metadata lock
waiting for stored procedure metadata lock
waiting for table level lock
Waiting for table metadata lock
waiting for trigger metadata lock (added in MySQL 5.5.8)
Wait for each kind of table lock.
Waiting on cond
A generic the which the thread is waiting for a condition to become true. No specific state information is available.
A normal state in which a thread is waiting for a condition to be true. No specific status information is available.
Waiting to get Readlock
The thread has issued a FLUSH TABLES with read lock statement to obtain a global READ lock and are waiting to obtain the LO Ck. This is removed in MySQL 5.5.8; Waiting for global read lock is used instead.
The thread issues a flush TABLES with read lock statement to obtain a global read lock, and waits for the lock to be obtained. This state is removed in MySQL 5.5.8 and is replaced with waiting for global read lock.
Writing to Net
The server is writing a packet to the network.
The server is writing a network packet.
Mysql-show Processlist Finishing (Turn)