1.IO THREAD
| MySQL有很多后台线程 其中包括了负责IO的相关线程IO THREAD 1. 参数innodb_write_io_threads 写线程 默认四个，负责数据块的写入 2. 参数innodb_read_io_threads 读线程 默认四个，负责数据块的读取 上面两个参数高并发下，可以设置为8. |
2.Purge thread
| 作用: 真正的删除记录和删除undo log 1.清理删除后的数据页的空间(因为之前的删除只是打上删除标签,并没有正真删除), 2.清理undo 举例:表tb1中有记录pk=1，2，3; 此时delete from tb1 where pk=1; 1. 将pk=1的记录标记为删除(delete-mark，infobits)，数据库中pk=1的记录此时还是存在的，空间并没有被释放，该操作为同步操作(SQL执行完，也就标记完成了)。 2. purge ，该部分为后台线程(purge线程)异步操作，会真正的删除该记录，且空间被释放。purge线程是系统自动的，无法人工控制。 标记为已删除的原因: 1. 该事物可能需要回滚，先作保留。 2. 当事物1去删除pk=1且没有提交时， 事物2应该要能看到pk=1的记录(事物的隔离性)。 过滤条件是聚簇索引: 1. delete – 将该记录标记为 delete-mark 。 2. update – 将该记录 先物理delete (聚簇索引里主键相同的行最多只能有1个)，然后 insert (或者可以原地更新[in place update])(即使删除了，也可以通过undo进行还原)。 过滤条件是二级索引: 1. delete – 将该记录标记为 delete-mark 。 2. update – 将该记录标记为 delete-mark (索引列是columns + pk，即使是唯一索引更新也是和原来的不一样)，然后 insert 。 为什么没有insert” 1. insert操作是不需要异步去purge，因为insert的记录之前是不存在的; 2. 不存在记录(未提交)是没有别的事物能引用到的，所以insert以后，对应的undo可以直接删除，而不需要等待异步. purge 总结: 1. delete-mark的记录最后会被purge线程回收，Purge会检测记录上是否有其他事物在引用undo，如果没有就可以删除。 2. innodb_purge_threads (5.6以后)，可以设置的大一些，回收的速度会快一些。 innodb_purge_threads = 4 |
3.Insert-buffer thread
负责insert buffer与辅助索引的合并操作。
4.redo-log thread
负责重做日志缓冲的磁盘写入
5.Master thread(主线程)
|
后台进程Master thread 里面有两种循环，再循环内可以调用其他线程进行相关的操作。 master thread的线程优先级别最高。 其内部几个循环(loop)组成：主循环(loop)，后台循环(background loop)，刷新循环(flush loop)，暂停循环(suspend loop)。 主循环有1s循环和10s循环. 1s循环即循环执行一次就sleep 1s后又执行一次又sleep 1 s. srv_master_thread loops: 745 1_second, 744 sleeps, 60 10_second, 179 background, 179 flush srv_master_thread log flush and writes: 744 各种循环执行的次数，据此判断系统负载高低 |