优化

我们先看一下与网络连接的性能配置项及对性能的影响。
●max_conecctions：整个MySQL允许的最大连接数；
这个参数主要影响的是整个MySQL应用的并发处理能力，当系统中实际需要的连接量大于
max_conecctions的情况下，由于MySQL的设置限制，那么应用中必然会产生连接请求的等待，
从而限制了相应的并发量。所以一般来说，只要MySQL主机性能允许，都是将该参数设置的尽
可能大一点。一般来说500到800左右是一个比较合适的参考值
●max_user_connections：每个用户允许的最大连接数；
上面的参数是限制了整个MySQL的连接数，而max_user_connections则是针对于单个用户的连
接限制。在一般情况下我们可能都较少使用这个限制，只有在一些专门提供MySQL数据存储服
务，或者是提供虚拟主机服务的应用中可能需要用到。除了限制的对象区别之外，其他方面和
max_connections一样。这个参数的设置完全依赖于应用程序的连接用户数，对于普通的应用来
说，完全没有做太多的限制，可以尽量放开一些。
●net_buffer_length：网络包传输中，传输消息之前的netbuffer初始化大小；
这个参数主要可能影响的是网络传输的效率，由于该参数所设置的只是消息缓冲区的初始化大
小，所以造成的影响主要是当我们的每次消息都很大的时候MySQL总是需要多次申请扩展该缓
冲区大小。系统默认大小为16KB，一般来说可以满足大多数场景，当然如果我们的查询都是非
常小，每次网络传输量都很少，而且系统内存又比较紧缺的情况下，也可以适当将该值降低到
8KB。
●max_allowed_packet：在网络传输中，一次传消息输量的最大值；
这个参数与net_buffer_length相对应，只不过是netbuffer的最大值。当我们的消息传输量
大于net_buffer_length的设置时，MySQL会自动增大netbuffer的大小，直到缓冲区大小达
到max_allowed_packet所设置的值。系统默认值为1MB，最大值是1GB，必须设定为1024的倍
数，单位为字节。
●back_log：在MySQL的连接请求等待队列中允许存放的最大连接请求数。
连接请求等待队列，实际上是指当某一时刻客户端的连接请求数量过大的时候，MySQL主线程没
办法及时给每一个新的连接请求分配（或者创建）连接线程的时候，还没有分配到连接线程的
所有请求将存放在一个等待队列中，这个队列就是MySQL的连接请求队列。当我们的系统存在
瞬时的大量连接请求的时候，则应该注意back_log参数的设置。系统默认值为50，最大可以设
置为65535。当我们增大back_log的设置的时候，同时还需要主义OS级别对网络监听队列的限
制，因为如果OS的网络监听设置小于MySQL的back_log设置的时候，我们加大“back_log”设
置是没有意义的。
上面介绍了网络连接交互相关的主要优化设置，下面我们再来看看与每一个客户端连接想对应的连
接线程。
在MySQL中，为了尽可提高客户端请求创建连接这个过程的性能，实现了一个ThreadCache池，将
空闲的连接线程存放在其中，而不是完成请求后就销毁。这样，当有新的连接请求的时候，MySQL首先会
检查ThreadCache池中是否存在空闲连接线程，如果存在则取出来直接使用，如果没有空闲连接线程，
才创建新的连接线程。在MySQL中与连接线程相关的系统参数及状态变量说明如下：
●thread_cache_size：ThreadCache池中应该存放的连接线程数。
当系统最初启动的时候，并不会马上就创建thread_cache_size所设置数目的连接线程存放在
ThreadCache池中，而是随着连接线程的创建及使用，慢慢的将用完的连接线程存入其中。当
存放的连接线程达到thread_cache_size值之后，MySQL就不会再续保存用完的连接线程了。
如果我们的应用程序使用的短连接，ThreadCache池的功效是最明显的。因为在短连接的数据
库应用中，数据库连接的创建和销毁是非常频繁的，如果每次都需要让MySQL新建和销毁相应
的连接线程，那么这个资源消耗实际上是非常大的，而当我们使用了ThreadCache之后，由于
连接线程大部分都是在创建好了等待取用的状态，既不需要每次都重新创建，又不需要在使用
完之后销毁，所以可以节省下大量的系统资源。所以在短连接的应用系统中，
thread_cache_size的值应该设置的相对大一些，不应该小于应用系统对数据库的实际并发请求
数。
而如果我们使用的是长连接的时候，ThreadCache的功效可能并没有使用短连接那样的大，但
也并不是完全没有价值。因为应用程序即使是使用了长连接，也很难保证他们所管理的所有连
接都能处于很稳定的状态，仍然会有不少连接关闭和新建的操作出现。在有些并发量较高，应
用服务器数量较大的系统中，每分钟十來次的连接创建与关闭的操作是很常见的。而且如果应
用服务器的连接池管理不是太好，容易产生连接池抖动的话，所产生的连接创建和销毁操作将
会更多。所以即使是在使用长连接的应用环境中，ThreadCache机制的利用仍然是对性能大有
帮助的。只不过在长连接的环境中我们不需要将thread_cache_size参数设置太大，一般来说
可能50到100之间应该就可以了。
●thread_stack：每个连接线程被创建的时候，MySQL给他分配的内存大小。
当MySQL创建一个新的连接线程的时候，是需要给他分配一定大小的内存堆栈空间，以便存放
客户端的请求Query以及自身的各种状态和处理信息。不过一般来说如果不是对MySQL的连接线
程处理机制十分熟悉的话，不应该轻易调整该参数的大小，使用系统的默认值（192KB）基本上
可以所有的普通应用环境。如果该值设置太小，会影响MySQL连接线程能够处理客户端请求的
Query内容的大小，以及用户创建的Procedures和Functions等

计算出系统新建连接连接的Thread
Cache命中率，也就是通过ThreadCache池中取得连接线程的次数与系统接收的总连接次数的比率，如
下：
Threads_Cache_Hit=(Connections-Threads_created)/Connections*100%
我们可以通过上面的这个运算公式计算一下上面环境中的ThreadCache命中率：Thread_Cache_Hit
=(127-12)/127*100%=90.55%
一般来说，当系统稳定运行一段时间之后，我们的ThreadCache命中率应该保持在90%左右甚至更
高的比率才算正常。可以看出上面环境中的ThreadCache命中比率基本还算是正常的。
TableCache相关的优化
我们先来看一下MySQL打开表的相关机制。由于多线程的实现机制，为了尽可能的提高性能，在
MySQL中每个线程都是独立的打开自己需要的表的文件描述符，而不是通过共享已经打开的表的文件描述
符的机制来实现。当然，针对于不同的存储引擎可能有不同的处理方式。如MyISAM表，每一个客户端线
程打开任何一个MyISAM表的数据文件都需要打开一个文件描述符，但如果是索引文件，则可以多个线程
共享同一个索引文件的描述符。对于Innodb的存储引擎，如果我们使用的是共享表空间来存储数据，那
么我们需要打开的文件描述符就比较少，而如果我们使用的是独享表空间方式来存储数据，则同样，由
于存储表数据的数据文件较多，则同样会打开很多的表文件描述符。除了数据库的实际表或者索引打开
以外，临时文件同样也需要使用文件描述符，同样会占用系统中open_files_limit的设置限额。
为了解决打开表文件描述符太过频繁的问题，MySQL在系统中实现了一个TableCache的机制，和前
面介绍的ThreadCache机制有点类似，主要就是Cache打开的所有表文件的描述符，当有新的请求的时
候不需要再重新打开，使用结束的时候也不用立即关闭。通过这样的方式来减少因为频繁打开关闭文件
描述符所带来的资源消耗。我们先看一看TableCache相关的系统参数及状态变量。
在MySQL中我们通过table_cache（从MySQL5.1.3开始改为table_open_cache），来设置系统中为
我们Cache的打开表文件描述符的数量。通过MySQL官方手册中的介绍，我们设置table_cache大小的时
候应该通过max_connections参数计算得来，公式如下：
table_cache=max_connections*N；
其中N代表单个Query语句中所包含的最多Table的数量。但是我个人理解这样的计算其实并不是太
准确，分析如下：
首先，max_connections是系统同时可以接受的最大连接数，但是这些连接并不一定都是active状
态的，也就是说可能里面有不少连接都是处于Sleep状态。而处于Sleep状态的连接是不可能打开任何
Table的。
其次，这个N为执行Query中包含最多的Table的Query所包含的Table的个数也并不是太合适，因
为我们不能忽略索引文件的打开。虽然索引文件在各个连接线程之间是可以共享打开的连接描述符的，
但总还是需要的。而且，如果我Query中的每个表的访问都是通过现通过索引定位检索的，甚至可能还
是通过多个索引，那么该Query的执行所需要打开的文件描述符就更多了，可能是N的两倍甚至三倍。
最后，这个计算的公式只能计算出我们同一时刻需要打开的描述符的最大数量，而table_cache的
设置也不一定非得根据这个极限值来设定，因为table_cache所设定的只是Cache打开的描述符的数量的
大小，而不是最多能够打开的量的大小。

join_buffer_size：当我们的Join是ALL，index，rang或者index_merge的时候使用的
Buffer；
实际上这种Join被称为FullJoin。实际上参与Join的每一个表都需要一个JoinBuffer，所以在
Join出现的时候，至少是两个。JoinBuffer的设置在MySQL5.1.23版本之前最大为4GB，但是从
5.1.23版本开始，在除了Windows之外的64位的平台上可以超出4BG的限制。系统默认是128KB。
●sort_buffer_size：系统中对数据进行排序的时候使用的Buffer；
SortBuffer同样是针对单个Thread的，所以当多个Thread同时进行排序的时候，系统中就会出现
多个SortBuffer。一般我们可以通过增大SortBuffer的大小来提高ORDERBY或者是GROUPBY
的处理性能。系统默认大小为2MB，最大限制和JoinBuffer一样，在MySQL5.1.23版本之前最大
为4GB，从5.1.23版本开始，在除了Windows之外的64位的平台上可以超出4GB的限制。
如果应用系统中很少有Join语句出现，则可以不用太在乎join_buffer_size参数的大小设置，但是
如果Join语句不是很少的话，个人建议可以适当增大join_buffer_size的设置到1MB左右，如果内存充
足甚至可以设置为2MB。对于sort_buffer_size参数来说，一般设置为2MB到4MB之间可以满足大多数
应用的需求。当然，如果应用系统中的排序都比较大，内存充足且并发量不是特别的大的时候，也可以
继续增大sort_buffer_size的设置。在这两个Buffer设置的时候，最需要注意的就是不要忘记是每个
Thread都会创建自己独立的Buffer，而不是整个系统共享的Buffer，不要因为设置过大而造成系统内存
不足。

[mysqld]
query_cache_size=512M
query_cache_type=1