for one connection. however, since the threads that perform the parallel scans are considered background threads, for this discussion you can consider the connection single threaded.
Each thread has an id which is what uniquely identifies the thread, and the column storing this id in the Performance Schema tables is called THREAD_ID. The main table for inspecting threads is the threads table with Listing 5-1 showing a typical example of the type of threads that exist in MySQL 8. The number of threads and exact thread types available depend on your configuration and usage of the instance at the time of querying the threads table.
Listing 5-1. Threads in MySQL 8 mysql> SELECT THREAD_ID AS TID,
SUBSTRING_INDEX(NAME, '/', -2) AS THREAD_NAME, IF(TYPE = 'BACKGROUND', '*', ") AS B,
IFNULL(PROCESSLIST_ID, ") AS PID FROM performance_schema.threads;
+---+---+---+---+
| TID | THREAD_NAME | B | PID | +---+---+---+---+
| 1 | sql/main | * | |
| 2 | mysys/thread_timer_notifier | * | |
| 4 | innodb/io_ibuf_thread | * | |
| 5 | innodb/io_log_thread | * | |
| 6 | innodb/io_read_thread | * | |
| 7 | innodb/io_read_thread | * | |
| 8 | innodb/io_read_thread | * | |
| 9 | innodb/io_read_thread | * | |
| 10 | innodb/io_write_thread | * | |
| 11 | innodb/io_write_thread | * | |
| 12 | innodb/io_write_thread | * | |
| 13 | innodb/io_write_thread | * | |
80
| 14 | innodb/page_flush_coordinator_thread | * | |
| 15 | innodb/log_checkpointer_thread | * | |
| 16 | innodb/log_closer_thread | * | |
| 17 | innodb/log_flush_notifier_thread | * | |
| 18 | innodb/log_flusher_thread | * | |
| 19 | innodb/log_write_notifier_thread | * | |
| 20 | innodb/log_writer_thread | * | |
| 21 | innodb/srv_lock_timeout_thread | * | |
| 22 | innodb/srv_error_monitor_thread | * | |
| 23 | innodb/srv_monitor_thread | * | |
| 24 | innodb/buf_resize_thread | * | |
| 25 | innodb/srv_master_thread | * | |
| 26 | innodb/dict_stats_thread | * | |
| 27 | innodb/fts_optimize_thread | * | |
| 28 | mysqlx/worker | | 9 |
| 29 | mysqlx/acceptor_network | * | |
| 30 | mysqlx/acceptor_network | * | |
| 31 | mysqlx/worker | * | |
| 34 | innodb/buf_dump_thread | * | |
| 35 | innodb/clone_gtid_thread | * | |
| 36 | innodb/srv_purge_thread | * | |
| 37 | innodb/srv_purge_thread | * | |
| 38 | innodb/srv_worker_thread | * | |
| 39 | innodb/srv_worker_thread | * | |
| 40 | innodb/srv_worker_thread | * | |
| 41 | innodb/srv_worker_thread | * | |
| 42 | innodb/srv_worker_thread | * | |
| 43 | innodb/srv_worker_thread | * | |
| 44 | sql/event_scheduler | | 4 |
| 45 | sql/compress_gtid_table | | 6 |
| 46 | sql/con_sockets | * | |
| 47 | sql/one_connection | | 7 |
| 48 | mysqlx/acceptor_network | * | |
| 49 | innodb/parallel_read_thread | * | |
| 50 | innodb/parallel_read_thread | * | | ChAPTEr 5 ThE PErfOrmAnCE SChEmA
| 51 | innodb/parallel_read_thread | * | |
| 52 | innodb/parallel_read_thread | * | | +---+---+---+---+
49 rows in set (0.0615 sec)
The TID column is the THREAD_ID for each thread, the THREAD_NAME column includes the two last components of the thread name (the first component is thread for all threads), the B column has an asterisk for the background threads, and the PID column has the process list id for the foreground threads.
Note Unfortunately, the term thread is overloaded in mySQL and is in some places used as a synonym for a connection. In this book, a connection refers to a user connection, and a thread refers to a Performance Schema thread, that is, it can either be a background or foreground (including connections) thread. The exception is when discussing a table that explicitly violates that convention.
The list of threads shows several important concepts for threads. The process list id and the thread id are not related. In fact, the thread with thread id = 28 has a higher process list id (9) than the thread with thread id 44 (4). So it is not even guaranteed that the order is the same (though for non-mysqlx threads it is in general the case).
For the mysqlx/worker threads, one is a foreground thread and the other a
background thread. This reflects how MySQL handles connections using the X Protocol which is considerably different from how classic connections are handled.
There are also “hybrid” threads that are not fully a background nor fully a foreground thread. An example is the sql/compress_gtid_table thread which compresses
the mysql.gtid_executed table. It is a foreground thread, yet if you execute SHOW PROCESSLIST, then it will not be included.
Tip The performance_schema.threads table is very useful and also includes
all the information displayed by SHOW PROCESSLIST . As there is less overhead
querying this table compared to executing SHOW PROCESSLIST or querying the
information_schema.PROCESSLIST table, using the threads table along with
the sys.processlist and sys.session views is the recommended way to get
a list of connections.
82
It can sometimes be useful to obtain the thread id for a connection. There are two functions for this:
• PS_THREAD_ID(): Get the Performance Schema thread id for the connection id provided as an argument.
• PS_CURRENT_THREAD_ID(): Get the Performance Schema thread id for the current connection.
In MySQL 8.0.15 and earlier, use sys.ps_thread_id() instead and give an argument of NULL to get the thread id for the current connection. An example of using the functions is mysql> SELECT CONNECTION_ID(),
PS_THREAD_ID(13),
PS_CURRENT_THREAD_ID()\G
*************************** 1. row ***************************
CONNECTION_ID(): 13 PS_THREAD_ID(13): 54 PS_CURRENT_THREAD_ID(): 54 1 row in set (0.0003 sec)
Using these functions is equivalent to querying the PROCESSLIST_ID and THREAD_ID columns in the performance_schema.threads table to link a connection id with a thread id. Listing 5-2 shows an example of using the PS_CURRENT_THREAD_ID() function to query the threads table for the current connection.
Listing 5-2. Querying the threads table for the current connection mysql> SELECT *
FROM performance_schema.threads
WHERE THREAD_ID = PS_CURRENT_THREAD_ID()\G
*************************** 1. row ***************************
THREAD_ID: 54
NAME: thread/mysqlx/worker TYPE: FOREGROUND
PROCESSLIST_ID: 13 PROCESSLIST_USER: root PROCESSLIST_HOST: localhost
PROCESSLIST_DB: performance_schema ChAPTEr 5 ThE PErfOrmAnCE SChEmA
PROCESSLIST_COMMAND: Query PROCESSLIST_TIME: 0
PROCESSLIST_STATE: statistics PROCESSLIST_INFO: SELECT * FROM threads
WHERE THREAD_ID = PS_CURRENT_THREAD_ID() PARENT_THREAD_ID: 1
ROLE: NULL INSTRUMENTED: YES HISTORY: YES CONNECTION_TYPE: SSL/TLS THREAD_OS_ID: 31516 RESOURCE_GROUP: SYS_default 1 row in set (0.0005 sec)
There are several of the columns that provide useful information in the context of performance tuning and will be used in later chapters. Worth noting here are the columns whose names start with PROCESSLIST_. These are equivalent of the information returned by SHOW PROCESSLIST, but querying the threads table causes less impact on the connections. The INSTRUMENTED and HISTORY columns specify whether instrumentation data is collected for the thread and whether the history of events is kept for the thread.
You can update these two columns to change the behavior of a thread, or you can define the default behavior for the threads based on the thread type in the setup_threads table or based on the account using the setup_actors table. That begs the question what instruments and events are. The three next sections discuss that as well as how the instrumentations are consumed.