Mysql-show Processlist Finishing

System Lock

Show processlist

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:

After create

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.

Analyzing

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)

Checking permissions

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.

Checking table

The thread is performing a table check operation.

The thread is performing a table check operation.

Cleaning up

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.

Closing tables

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 8.4.3.3, "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.

Creating Index

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.

Creating table

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.

Discard_or_import_tablespace

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.

End

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.

Executing

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.

Freeing items

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.

Flushing tables

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.

Fulltext initialization

The server is preparing to perform a natural-language full-text search.

The server is preparing for a natural language full-text search.

Init

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.

Killed

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.

Locked

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.

Null

This was used for the SHOW processlist state.

There is no operational status.

Login

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.

Manage keys

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.

Optimizing

The server is performing initial optimizations for a query.

The server performs a preliminary optimization of the query.

Preparing

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.

Query end

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.

removing duplicates

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.

Rename

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.

Reopen tables

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.

Repair Done

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.

Rolling back

The thread is rolling back a transaction.

Thread is rolling back a transaction

Saving state

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.

Sending data

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.

Setup

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.

Sorting index

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.

sorting result

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.

Statistics

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.

System Lock

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)

Table Lock

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.

Updating

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.

User Lock

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)

User Sleep

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.

Waiting for Lock_typeLock

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