allocating local table

Preparing to allocate rows to the delayed-insert handler thread. Follows from the got handler lock state.

Creating delayed handler

Creating a handler for the delayed-inserts.

got handler lock

Lock to access the delayed-insert handler thread has been received. Follows from the waiting for handler lock state and before the allocating local table state.

got old table

The initialization phase is over. Follows from the waiting for handler open state.

storing row into queue

Adding new row to the list of rows to be inserted by the delayed-insert handler thread.

waiting for delay_list

Initializing (trying to find the delayed-insert handler thread).

waiting for handler insert

Waiting for new inserts, as all inserts have been processed.

waiting for handler lock

Waiting for delayed insert-handler lock to access the delayed-insert handler thread.

waiting for handler open

Waiting for the delayed-insert handler thread to initialize. Follows from the Creating delayed handler state and before the got old table state.

insert

About to insert rows into the table.

reschedule

Sleeping in order to let other threads function, after inserting a number of rows into the table.

upgrading lock

Attempting to get lock on the table in order to insert rows.

Waiting for INSERT

Waiting for the delayed-insert connection thread to add rows to the queue.

Clearing

Thread is terminating.

Initialized

Thread has be initialized.

Waiting for next activation

The event queue contains items, but the next activation is at some time in the future.

Waiting for scheduler to stop

Waiting for the event scheduler to stop after issuing SET GLOBAL event_scheduler=OFF.

Waiting on empty queue

Sleeping, as the event scheduler's queue is empty.

After create

The function that created (or tried to create) a table (temporary or non-temporary) has just ended.

Analyzing

Calculating table key distributions, such as when running an ANALYZE TABLE statement.

checking permissions

Checking to see whether the permissions are adequate to perform the statement.

Checking table

Checking the table.

cleaning up

Preparing to reset state variables and free memory after executing a command.

closing tables

Flushing the changes to disk and closing the table. This state will only persist if the disk is full or under extremely high load.

converting HEAP to Aria

Converting an internal MEMORY temporary table into an on-disk Aria temporary table.

converting HEAP to MyISAM

Converting an internal MEMORY temporary table into an on-disk MyISAM temporary table.

copy to tmp table

A new table has been created as part of an ALTER TABLE statement, and rows are about to be copied into it.

Copying to group table

Sorting the rows by group and copying to a temporary table, which occurs when a statement has different GROUP BY and ORDER BY criteria.

Copying to tmp table

Copying to a temporary table in memory.

Copying to tmp table on disk

Copying to a temporary table on disk, as the resultset is too large to fit into memory.

Creating index

Processing an ALTER TABLE ... ENABLE KEYS for an Aria or MyISAM table.

Creating sort index

Processing a SELECT statement resolved using an internal temporary table.

creating table

Creating a table (temporary or non-temporary).

Creating tmp table

Creating a temporary table (in memory or on-disk).

deleting from main table

Deleting from the first table in a multi-table delete, saving columns and offsets for use in deleting from the other tables.

deleting from reference tables

Deleting matched rows from secondary reference tables as part of a multi-table delete.

discard_or_import_tablespace

Processing an ALTER TABLE ... IMPORT TABLESPACE or ALTER TABLE ... DISCARD TABLESPACE statement.

end

State before the final cleanup of an ALTER TABLE, CREATE VIEW, DELETE, INSERT, SELECT, or UPDATE statement.

executing

Executing a statement.

Execution of init_command

Executing statements specified by the --init_command mariadb client option.

filling schema table

A table in the information_schema database is being built.

freeing items

Freeing items from the query cache after executing a command. Usually followed by the cleaning up state.

Flushing tables

Executing a FLUSH TABLES statement and waiting for other threads to close their tables.

FULLTEXT initialization

Preparing to run a full-text search. This includes running the fulltext search (MATCH ... AGAINST) and creating a list of the result in memory

init

About to initialize an ALTER TABLE, DELETE, INSERT, SELECT, or UPDATE statement. Could be performaing query cache cleanup, or flushing the binary log or InnoDB log.

Killed

Thread will abort next time it checks the kill flag. Requires waiting for any locks to be released.

Locked

Query has been locked by another query.

logging slow query

Writing statement to the slow query log.

NULL

State used for SHOW PROCESSLIST.

login

Connection thread has not yet been authenticated.

manage keys

Enabling or disabling a table index.

Opening table[s]

Trying to open a table. Usually very quick unless the limit set by table_open_cache has been reached, or an ALTER TABLE or LOCK TABLE is in progress.

optimizing

Server is performing initial optimizations in for a query.

preparing

State occurring during query optimization.

Purging old relay logs

Relay logs that are no longer needed are being removed.

query end

Query has finished being processed, but items have not yet been freed (the freeing items state.

Reading file

Server is reading the file (for example during LOAD DATA INFILE).

Reading from net

Server is reading a network packet.

Removing duplicates

Duplicated rows being removed before sending to the client. This happens when SELECT DISTINCT is used in a way that the distinct operation could not be optimized at an earlier point.

removing tmp table

Removing an internal temporary table after processing a SELECT statement.

rename

Renaming a table.

rename result table

Renaming a table that results from an ALTER TABLE statement having created a new table.

Reopen tables

Table is being re-opened after thread obtained a lock but the underlying table structure had changed, so the lock was released.

Repair by sorting

Indexes are being created with the use of a sort. Much faster than the related Repair with keycache.

Repair done

Multi-threaded repair has been completed.

Repair with keycache

Indexes are being created through the key cache, one-by-one. Much slower than the related Repair by sorting.

Rolling back

A transaction is being rolled back.

Saving state

New table state is being saved. For example, after, analyzing a MyISAM table, the key distributions, rowcount etc. are saved to the .MYI file.

Searching rows for update

Finding matching rows before performing an UPDATE, which is needed when the UPDATE would change the index used for the UPDATE

Sending data

Sending data to the client as part of processing a SELECT statement or other statements that returns data like INSERT ... RETURNING . Often the longest-occurring state as it also include all reading from tables and disk read activities. Where an aggregation or un-indexed filtering occurs there is significantly more rows read than what is sent to the client.

setup

Setting up an ALTER TABLE operation.

Sorting for group

Sorting as part of a GROUP BY

Sorting for order

Sorting as part of an ORDER BY

Sorting index

Sorting index pages as part of a table optimization operation.

Sorting result

Processing a SELECT statement using a non-temporary table.

statistics

Calculating statistics as part of deciding on a query execution plan. Usually a brief state unless the server is disk-bound.

System lock

Requesting or waiting for an external lock for a specific table. The storage engine determines what kind of external lock to use. For example, the MyISAM storage engine uses file-based locks. However, MyISAM's external locks are disabled by default, due to the default value of the skip_external_locking system variable. Transactional storage engines such as InnoDB also register the transaction or statement with MariaDB's transaction coordinator while in this thread state. See MDEV-19391 for more information about that.

Table lock

About to request a table's internal lock after acquiring the table's external lock. This thread state occurs after the System lock thread state.

update

About to start updating table.

Updating

Searching for and updating rows in a table.

updating main table

Updating the first table in a multi-table update, and saving columns and offsets for use in the other tables.

updating reference tables

Updating the secondary (reference) tables in a multi-table update

updating status

This state occurs after a query's execution is complete. If the query's execution time exceeds long_query_time, then Slow_queries is incremented, and if the slow query log is enabled, then the query is logged. If the SERVER_AUDIT plugin is enabled, then the query is also logged into the audit log at this stage. If the userstats plugin is enabled, then CPU statistics are also updated at this stage.

User lock

About to request or waiting for an advisory lock from a GET LOCK() call. For SHOW PROFILE, means requesting a lock only.

User sleep

A SLEEP() call has been invoked.

Waiting for commit lock

FLUSH TABLES WITH READ LOCK is waiting for a commit lock, or a statement resulting in an explicit or implicit commit is waiting for a read lock to be released. This state was called Waiting for all running commits to finish in earlier versions.

Waiting for global read lock

Waiting for a global read lock.

Waiting for table level lock

External lock acquired,and internal lock about to be requested. Occurs after the System lock state. In earlier versions, this was called Table lock.

Waiting for xx lock

Waiting to obtain a lock of type xx.

Waiting on cond

Waiting for an unspecified condition to occur.

Writing to net

Writing a packet to the network.

Finished reading one binlog; switching to next binlog

After completing one binary log, the next is being opened for sending to the slave.

Master has sent all binlog to slave; waiting for binlog to be updated

All events have been read from the binary logs and sent to the slave. Now waiting for the binary log to be updated with new events.

Sending binlog event to slave

An event has been read from the binary log, and is now being sent to the slave.

Waiting to finalize termination

State that only occurs very briefly while the thread is terminating.

checking privileges on cached query

Checking whether the user has permission to access a result in the query cache.

checking query cache for query

Checking whether the current query exists in the query cache.

invalidating query cache entries

Marking query cache entries as invalid as the underlying tables have changed.

sending cached result to client

A result found in the query cache is being sent to the client.

storing result in query cache

Saving the result of a query into the query cache.

Waiting for query cache lock

Waiting to take a query cache lock.

Checking master version

Checking the primary's version, which only occurs very briefly after establishing a connection with the primary.

Connecting to master

Attempting to connect to primary.

Queueing master event to the relay log

Event is being copied to the relay log after being read, where it can be processed by the SQL thread.

Reconnecting after a failed binlog dump request

Attempting to reconnect to the primary after a previously failed binary log dump request.

Reconnecting after a failed master event read

Attempting to reconnect to the primary after a previously failed request. After successfully connecting, the state will change to Waiting for master to send event.

Registering slave on master

Registering the replica on the primary, which only occurs very briefly after establishing a connection with the primary.

Requesting binlog dump

Requesting the contents of the binary logs from the given log file name and position. Only occurs very briefly after establishing a connection with the primary.

Waiting for master to send event

Waiting for binary log events to arrive after successfully connecting. If there are no new events on the primary, this state can persist for as many seconds as specified by the slave_net_timeout system variable, after which the thread will reconnect. Prior to MariaDB 10.6.18, MariaDB 10.11.8, MariaDB 11.0.6, MariaDB 11.1.5, MariaDB 11.2.4 and MariaDB 11.4.2, the time was from SLAVE START. From these versions, the time is since reading the last event.

Waiting for slave mutex on exit

Waiting for replica mutex while the thread is stopping. Only occurs very briefly.

Waiting for the slave SQL thread to free enough relay log space.

Relay log has reached its maximum size, determined by relay_log_space_limit (no limit by default), so waiting for the SQL thread to free up space by processing enough relay log events.

Waiting for master update

State before connecting to primary.

Waiting to reconnect after a failed binlog dump request

Waiting to reconnect after a binary log dump request has failed due to disconnection. The length of time in this state is determined by the MASTER_CONNECT_RETRY clause of the CHANGE MASTER TO statement.

Waiting to reconnect after a failed master event read

Sleeping while waiting to reconnect after a disconnection error. The time in seconds is determined by the MASTER_CONNECT_RETRY clause of the CHANGE MASTER TO statement.

Changing master

Processing a CHANGE MASTER TO statement.

Killing slave

Processing a STOP SLAVE statement.

Opening master dump table

A table has been created from a master dump and is now being opened.

Reading master dump table data

After the table created by a master dump (the Opening master dump table state) the table is now being read.

Rebuilding the index on master dump table

After the table created by a master dump has been opened and read (the Reading master dump table data state), the index is built.

Apply log event

Log event is being applied.

Making temp file

Creating a temporary file containing the row data as part of a LOAD DATA INFILE statement.

Reading event from the relay log

Reading an event from the relay log in order to process the event.

Slave has read all relay log; waiting for the slave I/O thread to update it

All relay log events have been processed, now waiting for the I/O thread to write new events to the relay log.

Waiting for work from SQL thread

In parallel replication the worker thread is waiting for more things from the SQL thread.

Waiting for prior transaction to start commit before starting next transaction

In parallel replication the worker thread is waiting for conflicting things to end before starting executing.

Waiting for worker threads to be idle

Happens in parallel replication when moving to a new binary log after a master restart. All slave temporary files are deleted and worker threads are restarted.

Waiting due to global read lock

In parallel replication when worker threads are waiting for a global read lock to be released.

Waiting for worker threads to pause for global read lock

FLUSH TABLES WITH READ LOCK is waiting for worker threads to finish what they are doing.

Waiting while replication worker thread pool is busy

Happens in parallel replication during a FLUSH TABLES WITH READ LOCK or when changing number of parallel workers.

Waiting for other master connection to process GTID received on multiple master connections

A worker thread noticed that there is already another thread executing the same GTID from another connection and it's waiting for the other to complete.

Waiting for slave mutex on exit

Thread is stopping. Only occurs very briefly.

Waiting for the next event in relay log

State before reading next event from the relay log.