mysql线程什么意思

通俗点说，线程与进程都是为了更充足地利用CPU资源。要把程序更有序更高效地让CPU执行，就需要先把程序分块处理，而 *** 作系统可以把程序视为进程进行调度，有多少程序在运行就有多少进程。但有些程序可能会占用很大块CPU资源，如果不再把进程再细分无法更高效利用CPU资源，就把进程分成多个线程。如何分线程是程序自己的事。

mysql是多线程架构，一个查询或者一个过程可以按其运算属性再分开多个线程进行运算，这个线程多少由配置决定，大多数我们不必理mysql线程数，除了需要对mysql深度优化。mysql一个实例就是一个进程，一般情况下mysql进程就一个，而也可以同时启动多个MYSQL实例，这时就会有多个MYSQL进程。

在实际应用下，使用多个MYSQL实例并不多见，如果担心WEB服务与MYSQL进程互相争夺资源会影响数据处理的效率，可以把MYSQL分到独立的服务器。

从5.5.16开始，在MySQL的商业化版本中将Thread Pool作为plugin提供官方功能支持。在之前的版本中，线程处理模式包括两种：no-threads(单线程处理，多用于debug)、one-thread-per-connection（每个请求对应一个线程，目前被作为默认值）；在支持thread pool功能的版本中，thread_handling则需设置为dynamically-loaded。

最初当我看到说MySQL会支持Thread Pool这个功能的时候，我很疑惑，心想不是已经有thread_cache_size来提高线程的重复利用率，为嘛还要弄个专门的池子呢。之前，有听过connection pool，是在一些应用服务器端来支持类似的功能。我们都知道，当应用发起一个对数据库的 *** 作时，在整个应用中是一个不小的开销，从建立连接之初，CPU要给它划分一定的thread stack，然后进行用户身份认证，建立上下文信息，最后请求完成，关闭连接，同时释放资源，可以称的上是秒级的过程，在高并发的情况下，将给系统带来巨大的压力更不能保证性能。所以，采用线程重用，减小这部分的消耗。MySQL通过thread_cache_size这参数，来设置可以重用线程的个数，在生产过程中，通过一些状态参数来把握合适的重用线程数，比如：threads_cached可以知道目前有还有多少线程可用，通过threads_created参数的增长趋势可以判断是否需要加大需要cache住线程的个数。需要清楚的是目前，线程处理的模式是，每个请求就对应一个线程的模式，这就意味着当有成千上万的请求时，对应的也就需要成千上万的线程来相应这些请求，那么此刻问题就很明显了，系统的资源是有限的，必须要保证thread_number*thread_stack不能超过可以使用的内存资源，还要考虑CPU的调度能力，I/O的处理能力，这是一种很粗放的资源使用方式，不是吗？同时，这种不加控制的处理方式，也会带来资源使用的冲突，大量互斥锁的出现，性能的急剧下降。通过Thread Pool来控制确保不会超过服务器的最大负载能力，避免出现服务无响应，导致宕机的惨状。（既然在应用服务器端有connection pool，为什么还需要在数据库服务器端实现thread pool呢？）

在看了一些相关的资料和对于Thread Pool实现方式讨论之后，我目前最深刻的体会就是，控制，一个平衡的控制。没错，你可以说thread pool是为了提升性能，难道不是吗？我们所做的一切都是为了性能。但，如何让性能维持在一个稳定的状态，这才是当我们得到一个好的预期之后，我们更需要关心的重点。更多时候，系统的性能会随着并发的升高而随着或急或慢的下降，其实，我们更需要采用一种方式去做的时刻动态调整来为维持系统的稳定性能，减少波动，这对于我们的应用来说才会获得一个理想的性能。

我觉得，这更像是在跑马拉松，在整个过程中，不会因为你某一端跑的比别人快，最后一定就会第一个通过终点，而是取决于你以一个合理的速度在不断超越每一个身边的人，当你发现落后太多时适当提高速度，当体力透支时适当减慢速度，合理分担体能，保持稳定高效的前进。

关于Thread Pool的功能细节，大家可以去看手册5.5中相关章节的内容在7.11.6 The Thread Pool Plugin。本来想写一下，因为自己并没有亲自用过，就是放个中文在这里也没有多大用，想想还是算了，浪费大家时间（p.s.: Blog不应该是单纯的翻译，而且更不应该翻译的内容可能自己都没有用过的，只是可怜的how to install &configure :P）。

生产环境中，MySQL 不经意间吃掉全部的内容，然后开始吃掉 SWAP，性能一降再降，怎么办？

可以从下面三点查看原因：

MySQL 使用内存，有两个途径。

永久占用的内容

比如全局缓冲区（Global Buffer）类别，是在服务器启动期间从 *** 作系统获得的，不会释放到任何一个别的进程。

动态请求的内存

线程缓冲区由MySQL使用，它是在处理新查询时从 *** 作系统请求的内存。在执行查询之后，该内存被释放回 *** 作系统。

这意味着 MySQL 的内存使用，是 全局缓冲区 加上 线程缓冲区 以及 允许的最大连接数 。

对于专用数据库服务器，该值需要保持在服务器内存的90%以下。在共享服务器的情况下，它应该保持在服务器内存的50%以下。

检查一下 MySQL 设置，有助于确定内存使用情况，从而为 MySQL 分配合适的值。

一个近似的公式：

当网站受到攻击时，有可能在短时间内建立异常高的连接数量。MySQL 中的 PROCESSLIST 可用于检测顶级用户并阻止对滥用连接的访问。

找出查询需要很长时间才能执行的语句，因为这些查询需要进一步优化服务器才能更好地执行，可以通过服务器查询日志进行识别。由于查询速度慢，导致磁盘读取较多，导致内存和CPU使用率较高，影响服务器性能。

最后，到了加内存条的时候了。虽然在优化数据库设置之后，服务器会不断地路由到使用交换内存，但也必须增加内存。俗话说：“巧妇难为无米之炊”，就是这个意思。

上面说的这些方向，大家可以在实际 *** 作中验证体会，希望大家在数据库优化的路上，麻溜顺畅，砥砺前行。

---