MySQL线程

当MySQL服务器本身遇到性能问题的时候，一般可以通过slow log来找到耗时比较多的SQL语句，并且进一步通过explain来优化和改进SQL执行速度。这种方法有这几方面的限制：首先，并不是所有的问题都是因为异常SQL造成的，当大量SQL请求时间比较长，但不到slow log阈值的时候（通常线上无法将slow log阈值设置的较小），MySQL服务器负载也会很高；其次，MySQL服务器本身的状态会影响SQL的执行，有一些没有问题的SQL语句在MySQL负载较高时，也会进入slow log。

另外一种方法是通过MySQL的Performance Schema、Innodb status以及MySQL status等MySQL统计信息来定位问题；这通常需要对MySQL的实现有相当的了解；并且定位问题不是非常直接。

本人认为除了以上两种办法之外，可以通过strace MySQL的线程来定位性能瓶颈。这种方法可以定位出因为系统IO（包括网络）、内存、线程同步（MySQL锁使用错误）等造成的问题；也就是说，如果能确定MySQL Server不存在大量需要在用户态进行的计算（例如浮点运算、字符串处理等），都可以尝试使用此方法。

下面将介绍MySQL线程相关的一些信息，以MySQL5.6.29为例，MySQL5.7会有一些不一样。

1、多线程程序

MySQL只有一个进程，使用多线程实现并发。使用InnoDB作为存储引擎的情况下，主要关注MySQL和InnoDB创建的线程。

可以使用MySQL的Performance Schema.threads表来查看MySQL的线程。这个表含所有MySQL创建并活跃的线程以及部分InnoDB线程。

2、线程池

每次和MySQL Server建立连接，MySQL服务器都会创建或分配一个线程处理对应的请求。

MySQL会维护一个线程池管理这些工作线程。只有当工作线程的正在响应请求时，才会进入Performance Schema.threads表。可以通过向MySQL进程发送SIGHUP信号来释放所有的线程并创建一个只有一个线程的线程池。

3、InnoDB线程

InnoDB会创建很多功能线程（都是运行期间常驻线程），用于处理异步任务。但也许InnoDB有很多代码是临时工写的，有部分线程没有使用MySQL提供的Performance Schema机制注册到threads表中。

4、线程对应

由于threads表中没有包含线程的系统id，甚至由于第2点和第3点的原因（部分线程不会出现在threads）表中，因此无法通过threads表将MySQL的线程对应到系统线程。

以下表为本人梳理的线程创建顺序及数量，可以通过将MySQL服务器按照线程ID进行排序，然后一一对应上。（注：由于MySQL在启动过程中需要创建一些临时线程，因此MySQL的线程ID并不是连续的）

下表所列CPU时间为本人的线上环境的某一个从库的时间。

创建顺序

线程名称

线程数量

线程作用

CPU时间

1

main

1

主线程

2

innodb ibuff io thread

1

innodb inser buff写入和读取线程

0s

3

innodb log io thread

1

innodb undo log写入和读取线程

1s

4

innodb read threads

innodb_read_io_threads

innodb数据库文件read ahead线程

9s*8

5

innodb write threads

innodb_write_io_threads

innodb数据库文件写入线程

2m*8

6

lock_wait_timeout_thread

1

watches the timeouts for lock waits

0.99s

7

srv_error_monitor_thread

1

warns of long semaphore waits

33s

8

srv_monitor_thread

1

prints InnoDB monitor info

0.15s

9

srv_master_thread

1

does purge and other utility operations

4s

10

srv_purge_coordinator_thread

1

redo log清理

1h

11

srv_worker_thread

innodb_purge_threads – 1

purge worker

12

buf_flush_page_cleaner_thread

1

flush page

53m

13

buf_dump_thread

1

buffer pool dump/load thread

0s

14

dict_stats_thread

1

dict stats gathering thread

0.11s

15

fts_optimize_thread

1

Optimize all FTS tables

0.15s

16

signal_handler

1

signal handler thread

0s

17

slave_io

1

slave io

19m

18

slave_sql

1

slave sql

11h

19

connection

n

handler

下一节，本人将分享关于使用strace跟踪线程的操作经验。