当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时间为本人的线上环境的某一个从库的时间。
