MySQL · 特性分析 · 线程池

## 概述 MySQL 原有线程调度方式有每个连接一个线程(one-thread-per-connection)和所有连接一个线程（no-threads）。 no-threads一般用于调试，生产环境一般用one-thread-per-connection方式。one-thread-per-connection 适合于低并发长连接的环境，而在高并发或大量短连接环境下，大量创建和销毁线程，以及线程上下文切换，会严重影响性能。另外 one-thread-per-connection 对于大量连接数扩展也会影响性能。 为了解决上述问题，MariaDB、Percona、Oracle MySQL 都推出了线程池方案，它们的实现方式大体相似，这里以 Percona 为例来简略介绍实现原理，同时会介绍我们在其基础上的一些改进。 ## 实现 线程池方案下，用户的每个连接不再对应一个线程。线程池由一系列 worker 线程组成，这些worker线程被分为`thread_pool_size`个group。用户的连接按 round-robin 的方式映射到相应的group 中，一个连接可以由一个group中的一个或多个worker线程来处理。 1. listener 线程 每个group中有一个listener线程，通过epoll的方式来监听本group中连接的事件。listener线程同时也是worker线程，listener线程不是固定的。 listener线程监听到连接事件后会将事件放入优先级队列中，listener线程作为worker线程也处理一些连接事件，以减少上下文切换。 listener线程会检查优先级队列是否为空，如果为空表示网络空闲，listener线程会作为worker线程处理第一个监听事件，其他事件仍然放入优先级队列中。 另外，当没有活跃线时，listener会唤醒一个线程，如果没有线程可以唤醒，且当前group只有一个线程且为listener，则创建一个线程。 2. 优先级队列 分为高优先级队列和普通队列，已经开启的事务并且tickets不为0，放入高优先队列，否则放入普通队列。每个连接在`thread_pool_high_prio_tickets`次被放到优先队列中后，会移到普通队列中。worker线程先从高优先队列取event处理，只有当高优先队列为空时才从普通队列取event处理。 通过优先级队列，可以让已经开启的事务或短事务得到优先处理，及时提交释放锁等资源。 3. worker 线程 worker线程负责从优先队列取事件处理。如果没有取到event，会尝试从epoll中取一个，如果没有取到再进入等待，如果等待超过`thread_pool_idle_timeout` worker线程会退出。 4. timer 线程 每隔`thread_pool_stall_limit`时间检查一次。 * listener没有接收新的事件，listener正在等待时需调用`wake_or_create_thread`，重新创建listener； * 从上一次检查起，worker线程没有收到新的事件，并且队列不为空，则认为发生了stall，需唤醒或创建worker线程； * 检查`net_wait_timeout`是否超时，如果超时退出连接，而不是退出worker线程。 5. 何时唤醒或创建worker线程 * 从队列中取事件时发现没有活跃线程时； * worker线程发生等待且没有活跃线程时； * timer线程认为发生了stall； ## 重要参数解析 1. `thread_pool_oversubscribe` 一个group中活跃线程和等待中的线程超过`thread_pool_oversubscribe`时，不会创建新的线程。 此参数可以控制系统的并发数，同时可以防止调度上的死锁，考虑如下情况，A、B、C三个事务，A、B 需等待C提交。A、B先得到调度，同时活跃线程数达到了`thread_pool_max_threads`上限，随后C继续执行提交，此时已经没有线程来处理C提交，从而导致A、B一直等待。`thread_pool_oversubscribe`控制group中活跃线程和等待中的线程总数，从而防止了上述情况。 2. `thread_pool_stall_limit` timer线程检测间隔。此参数设置过小，会导致创建过多的线程，从而产生较多的线程上下文切换，但可以及时处理锁等待的场景，避免死锁。参数设置过大，对长语句有益，但会阻塞短语句的执行。参数设置需视具体情况而定，例如99%的语句10ms内可以完成，那么我们可以将就`thread_pool_stall_limit`设置为10ms ## 一些改进 1. lock tables read 的处理 对于声明 lock tables read 等明确声明表锁的事件，放入高优先级队列。 2. binlog dump线程的处理 binlog dump线程是典型的长事务场景，当多个binlog dump线程分配到同一个group中时，group中的线程很容易超过`thread_pool_oversubscribe`限制，从而导致性能下降。 优化方法是修改binlog dump线程不受`thread_pool_oversubscribe`限制。 3. 丰富诊断信息`information_schema.thread_group_status` ~~~ show create table THREAD_GROUP_STATUS\G *************************** 1. row *************************** Table: THREAD_GROUP_STATUS Create Table: CREATE TEMPORARY TABLE `THREAD_GROUP_STATUS` ( `ID` int(21) unsigned NOT NULL DEFAULT '0', `THREAD_COUNT` int(21) unsigned NOT NULL DEFAULT '0', `ACTIVE_THREAD_COUNT` int(21) unsigned NOT NULL DEFAULT '0', `CONNECTION_COUNT` int(21) unsigned NOT NULL DEFAULT '0', `WAITING_THREAD_COUNT` int(21) unsigned NOT NULL DEFAULT '0', `DUMP_COUNT` bigint(21) unsigned NOT NULL DEFAULT '0', `LOW_QUEUE_COUNT` bigint(21) unsigned NOT NULL DEFAULT '0', `HIGH_QUEUE_COUNT` bigint(21) unsigned NOT NULL DEFAULT '0' ) ENGINE=MEMORY DEFAULT CHARSET=utf8 ~~~ 4. 线程池调度异常，无法连接的处理 对于本地登录的用户，走老的`one_thread_per_connection`逻辑，从而解决无法连接的情况。 ## 连接池和线程池的区别 最后说一点连接池和线程池的区别。连接池和线程池是两个独立的概念，连接池是在客户端的优化，缓存客户的连接，避免重复创建和销毁连接。而线程池是服务器端的优化。两者的优化角度不同，不相关，因此两种优化可以同时使用。