最大连接数
show variables max_connections;
select VARIABLE_VALUE from information_schema.GLOBAL_VARIABLES where VARIABLE_NAME='MAX_CONNECTIONS';
set global max_connections = 3600;
上面的是临时的，如果重新启动mysql，就会恢复到默认值.
要永久生效，可以在 my.cnf(linux下的配置文件),
在 [mysqld] 中添加
max_connections = 1000
max_user_connections,默认为0，表示连接用户不受限制
================================================
mysql物理文件组成
2.1.1 日志文件
1、错误日志：Error Log
错误日志记录了MyQL Server 运行过程中所有较为严重的警告和错误信息，以及MySQL
Server 每次启动和关闭的详细信息。在默认情况下，系统记录错误日志的功能是关闭的，
错误信息被输出到标准错误输出（stderr），如果要开启系统记录错误日志的功能，需要在
启动时开启-log-error 选项。错误日志的默认存放位置在数据目录下，以hostname.err 命
名。但是可以使用命令：--log-error[=file_name]，修改其存放目录和文件名。
2、二进制日志：Binary Log & Binary Log Index
二进制日志，也就是我们常说的binlog，也是MySQL Server 中最为重要的日志之一。
当我们通过“--log-bin[=file_name]”打开了记录的功能之后，MySQL 会将所有修改数据
库数据的query 以二进制形式记录到日志文件中。当然，日志中并不仅限于query 语句这么
简单，还包括每一条query 所执行的时间，所消耗的资源，以及相关的事务信息，所以binlog
是事务安全的。
和错误日志一样，binlog 记录功能同样需要“--log-bin[=file_name]”参数的显式指
定才能开启，如果未指定file_name，则会在数据目录下记录为mysql-bin.******（*代表0～
9 之间的某一个数字，来表示该日志的序号）。
binlog 还有其他一些附加选项参数：
“--max_binlog_size”设置binlog 的最大存储上限，当日志达到该上限时，MySQL 会
重新创建一个日志开始继续记录。不过偶尔也有超出该设置的binlog 产生，一般都是因为
在即将达到上限时，产生了一个较大的事务，为了保证事务安全，MySQL 不会将同一个事务
分开记录到两个binlog 中。
“--binlog-do-db=db_name”参数明确告诉MySQL，需要对某个（db_name）数据库记
录binlog，如果有了“--binlog-do-db=db_name”参数的显式指定，MySQL 会忽略针对其他
数据库执行的query，而仅仅记录针对指定数据库执行的query。
“--binlog-ignore-db=db_name”与“--binlog-do-db=db_name”完全相反，它显式指
定忽略某个（db_name）数据库的binlog 记录，当指定了这个参数之后，MySQL 会记录指定
数据库以外所有的数据库的binlog。
“--binlog-ignore-db=db_name”与“--binlog-do-db=db_name”两个参数有一个共同
的概念需要大家理解清楚，参数中的db_name 不是指query 语句更新的数据所在的数据库，
而是执行query 的时候当前所处的数据库。不论更新哪个数据库的数据，MySQL 仅仅比较当
前连接所处的数据库（通过use db_name 切换后所在的数据库）与参数设置的数据库名，而
不会分析query 语句所更新数据所在的数据库。
mysql-bin.index 文件（binary log index）的功能是记录所有Binary Log 的绝对路
径，保证MySQL 各种线程能够顺利的根据它找到所有需要的Binary Log 文件。
3、查询日志：query log
查询日志记录MySQL 中所有的query，通过“--log[=fina_name]”来打开该功能。由
于记录了所有的query，包括所有的select，体积比较大，开启后对性能也有较大的影响，
所以请大家慎用该功能。一般只用于跟踪某些特殊的sql 性能问题才会短暂打开该功能。默
认的查询日志文件名为hostname.log。
4、慢查询日志：slow query log
顾名思义，慢查询日志中记录的是执行时间较长的query，也就是我们常说的slow
query，通过设--log-slow-queries[=file_name]来打开该功能并设置记录位置和文件名，
默认文件名为hostname-slow.log，默认目录也是数据目录。
慢查询日志采用的是简单的文本格式，可以通过各种文本编辑器查看其中的内容。其中
记录了语句执行的时刻，执行所消耗的时间，执行用户，连接主机等相关信息。MySQL 还提
供了专门用来分析满查询日志的工具程序mysqlslowdump，用来帮助数据库管理人员解决可
能存在的性能问题。
5、Innodb 的在线redo 日志：innodb redo log
Innodb 是一个事务安全的存储引擎，其事务安全性主要就是通过在线redo 日志和记录
在表空间中的undo 信息来保证的。redo 日志中记录了Innodb 所做的所有物理变更和事务
信息，通过redo 日志和undo 信息，Innodb 保证了在任何情况下的事务安全性。Innodb 的redo
日志同样默认存放在数据目录下，可以通过innodb_log_group_home_dir 来更改设置日志的
存放位置，通过innodb_log_files_in_group 设置日志的数量。
最主要的日志就是 binlog了，因为这是很多存储引擎进行增量备份的基础，也是mysql实现
复制的基本条件.
Binlog相关参数及优化策略
通过执行如下命令可以获得关于Binlog 的相关参数
show variables like '%binlog%';
Innodb 存储引擎特有的与Binlog 相关的参数：
show variables like '%innodb_locks_unsafe_for_binlog%';
以上显示的结果参数分析：
“binlog_cache_size"：在事务过程中容纳二进制日志SQL 语句的缓存大小。二进制日志缓存是服
务器支持事务存储引擎并且服务器启用了二进制日志(—log-bin 选项)的前提下为每个客户端分配的内
存，注意，是每个Client 都可以分配设置大小的binlog cache 空间。如果读者朋友的系统中经常会
出现多语句事务的话，可以尝试增加该值的大小，以获得更有的性能。当然，我们可以通过MySQL 的以下两
个状态变量来判断当前的binlog_cache_size 的状况：Binlog_cache_use 和Binlog_cache_disk_use。
“max_binlog_cache_size”：和"binlog_cache_size"相对应，但是所代表的是binlog 能够使用的
最大cache 内存大小。当我们执行多语句事务的时候，max_binlog_cache_size 如果不够大的话，系统可
能会报出“ Multi-statement transaction required more than 'max_binlog_cache_size' bytes of
storage”的错误。
“max_binlog_size”：Binlog 日志最大值，一般来说设置为512M 或者1G，但不能超过1G。该大小
并不能非常严格控制Binlog 大小，尤其是当到达Binlog 比较靠近尾部而又遇到一个较大事务的时候，系
统为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL 都记录进入当前日志，
直到该事务结束.
“sync_binlog”：这个参数是对于MySQL 系统来说是至关重要的，他不仅影响到Binlog 对MySQL 所
带来的性能损耗，而且还影响到MySQL 中数据的完整性。
对于“sync_binlog”参数的各种设置的说明如下：
sync_binlog=0，当事务提交之后，MySQL 不做fsync 之类的磁盘同步指令刷新binlog_cache 中
的信息到磁盘，而让Filesystem 自行决定什么时候来做同步，或者cache 满了之后才同步到磁盘。
sync_binlog=n，当每进行n 次事务提交之后，MySQL 将进行一次fsync 之类的磁盘同步指令来
将binlog_cache 中的数据强制写入磁盘.
在MySQL 中系统默认的设置是sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性
能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache 中的所有binlog 信息都会被
丢失。而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为1 的时候，即使系统
Crash，也最多丢失binlog_cache 中未完成的一个事务，对实际数据没有任何实质性影响。从以往经验
和相关测试来看，对于高并发事务的系统来说，“sync_binlog”设置为0 和设置为1 的系统写入性能差
距可能高达5 倍甚至更多。
MySQL 的复制（Replication），实际上就是通过将Master 端的Binlog 通过利用IO 线
程通过网络复制到Slave 端，然后再通过SQL 线程解析Binlog 中的日志再应用到数据库中来实现的。所
以，Binlog 量的大小对IO 线程以及Msater 和Slave 端之间的网络都会产生直接的影响。
MySQL 中Binlog 的产生量是没办法改变的，只要我们的Query 改变了数据库中的数据，那么就必须
将该Query 所对应的Event 记录到Binlog 中。那我们是不是就没有办法优化复制了呢？当然不是，在
MySQL 复制环境中，实际上是是有8 个参数可以让我们控制需要复制或者需要忽略而不进行复制的DB 或
者Table 的，分别为：
Binlog_Do_DB：设定哪些数据库（Schema）需要记录Binlog；
Binlog_Ignore_DB：设定哪些数据库（Schema）不要记录Binlog；
Replicate_Do_DB：设定需要复制的数据库（Schema），多个DB 用逗号（“,”）分隔；
Replicate_Ignore_DB：设定可以忽略的数据库（Schema）；
Replicate_Do_Table：设定需要复制的Table；
Replicate_Ignore_Table：设定可以忽略的Table；
Replicate_Wild_Do_Table：功能同Replicate_Do_Table，但可以带通配符来进行设置；
Replicate_Wild_Ignore_Table：功能同Replicate_Ignore_Table，可带通配符设置；
通过上面这八个参数，就可以非常方便按照实际需求，控制从Master 端到Slave 端的Binlog
量尽可能的少，从而减小Master 端到Slave 端的网络流量，减少IO 线程的IO 量，还能减少SQL 线程的
解析与应用SQL 的数量，最终达到改善Slave 上的数据延时问题。
实际上，上面这八个参数中的前面两个是设置在Master 端的，而后面六个参数则是设置在Slave 端
的。虽然前面两个参数和后面六个参数在功能上并没有非常直接的关系，但是对于优化MySQL 的
Replication 来说都可以起到相似的功能.当然也有一定的区别，其主要区别如下:
如果在Master 端设置前面两个参数，不仅仅会让Master 端的Binlog 记录所带来的IO 量减少，
还会让Master 端的IO 线程就可以减少Binlog 的读取量，传递给Slave 端的IO 线程的Binlog
量自然就会较少。这样做的好处是可以减少网络IO，减少Slave 端IO 线程的IO 量，减少Slave
端的SQL 线程的工作量，从而最大幅度的优化复制性能。当然，在Master 端设置也存在一定的
弊端，因为MySQL 的判断是否需要复制某个Event 不是根据产生该Event 的Query 所更改的数据
所在的DB，而是根据执行Query 时刻所在的默认Schema，也就是我们登录时候指定的DB 或者运
行“USE DATABASE”中所指定的DB。只有当前默认DB 和配置中所设定的DB 完全吻合的时候IO
线程才会将该Event 读取给Slave 的IO 线程。所以如果在系统中出现在默认DB 和设定需要复制
的DB 不一样的情况下改变了需要复制的DB 中某个Table 的数据的时候，该Event 是不会被复制
到Slave 中去的，这样就会造成Slave 端的数据和Master 的数据不一致的情况出现。同样，如
果在默认Schema 下更改了不需要复制的Schema 中的数据，则会被复制到Slave 端，当Slave 端
并没有该Schema 的时候，则会造成复制出错而停止；
而如果是在Slave 端设置后面的六个参数，在性能优化方面可能比在Master 端要稍微逊色一
点，因为不管是需要还是不需要复制的Event 都被会被IO 线程读取到Slave 端，这样不仅仅增
加了网络IO 量，也给Slave 端的IO 线程增加了Relay Log 的写入量。但是仍然可以减少Slave
的SQL 线程在Slave 端的日志应用量。虽然性能方面稍有逊色，但是在Slave 端设置复制过滤机
制，可以保证不会出现因为默认Schema 的问题而造成Slave 和Master 数据不一致或者复制出错
的问题。
Slow Query Log 相关参数及使用建议
再来看看Slow Query Log 的相关参数配置。有些时候，我们为了定位系统中效率比较低下的Query
语句，则需要打开慢查询日志，也就是Slow Query Log。
我们可以如下查看系统慢查询日志的相关设置：
show variables like 'log_slow%';
show variables like 'long_query%';
log_slow_queries: 参数显示了系统是否已经打开Slow Query Log 功能，
而"long_query_time"参数则告诉我们当前系统设置的Slow Query 记录执行时间超过多长的Query。
打开Slow Query Log 功能对系统性能的整体影响没有Binlog 那么大，毕竟Slow Query Log 的数据
量比较小，带来的IO 损耗也就较小，但是，系统需要计算每一条Query 的执行时间，所以消耗总是会有
一些的，主要是CPU 方面的消耗。如果大家的系统在CPU 资源足够丰富的时候，可以不必在乎这一点点损
耗，毕竟他可能会给我们带来更大性能优化的收获。但如果我们的CPU 资源也比较紧张的时候，也完全
可以在大部分时候关闭该功能，而只需要间断性的打开Slow Query Log 功能来定位可能存在的慢查询。
--------------------------
2.1.2 数据文件
在MySQL 中每一个数据库都会在定义好（或者默认）的数据目录下存在一个以数据库名
字命名的文件夹，用来存放该数据库中各种表数据文件。不同的MySQL 存储引擎有各自不同
的数据文件，存放位置也有区别。多数存储引擎的数据文件都存放在和MyISAM 数据文件位
置相同的目录下，但是每个数据文件的扩展名却各不一样。如MyISAM 用“.MYD”作为扩展
名，Innodb 用“.ibd”，Archive 用“.arc”，CSV 用“.csv”，等等。
1、“.frm”文件
与表相关的元数据（meta）信息都存放在“.frm”文件中，包括表结构的定义信息等。
不论是什么存储引擎，每一个表都会有一个以表名命名的“.frm”文件。所有的“.frm”文
件都存放在所属数据库的文件夹下面。
2、“.MYD”文件
“.MYD”文件是MyISAM 存储引擎专用，存放MyISAM 表的数据。每一个MyISAM 表都会
有一个“.MYD”文件与之对应，同样存放于所属数据库的文件夹下，和“.frm”文件在一起。
3、“.MYI”文件
“.MYI”文件也是专属于MyISAM 存储引擎的，主要存放MyISAM 表的索引相关信息。对
于MyISAM 存储来说，可以被cache 的内容主要就是来源于“.MYI”文件中。每一个MyISAM
表对应一个“.MYI”文件，存放于位置和“.frm”以及“.MYD”一样。
4、“.ibd”文件和ibdata 文件
这两种文件都是存放Innodb 数据的文件，之所以有两种文件来存放Innodb 的数据（包
括索引），是因为Innodb 的数据存储方式能够通过配置来决定是使用共享表空间存放存储数
据，还是独享表空间存放存储数据。独享表空间存储方式使用“.ibd”文件来存放数据，且
每个表一个“.ibd”文件，文件存放在和MyISAM 数据相同的位置。如果选用共享存储表空
间来存放数据，则会使用ibdata 文件来存放，所有表共同使用一个（或者多个，可自行配
置）ibdata 文件。ibdata 文件可以通过innodb_data_home_dir 和innodb_data_file_path
两个参数共同配置组成， innodb_data_home_dir 配置数据存放的总目录， 而
innodb_data_file_path 配置每一个文件的名称。当然， 也可以不配置
innodb_data_home_dir 而直接在innodb_data_file_path 参数配置的时候使用绝对路径来
完成配置。innodb_data_file_path 中可以一次配置多个ibdata 文件。文件可以是指定大
小，也可以是自动扩展的，但是Innodb 限制了仅仅只有最后一个ibdata 文件能够配置成自
动扩展类型。当我们需要添加新的ibdata 文件的时候，只能添加在innodb_data_file_path
配置的最后，而且必须重启MySQL 才能完成ibdata 的添加工作。不过如果我们使用独享表
空间存储方式的话，就不会有这样的问题，但是如果要使用裸设备的话，每个表一个裸设备，
可能造成裸设备数量非常大，而且不太容易控制大小，实现比较困难，而共享表空间却不会
有这个问题，容易控制裸设备数量。我个人还是更倾向于使用独享表空间存储方式(默认就是这个)。
2.1.3 Replication相关文件
1、master.info 文件：
master.info 文件存在于Slave 端的数据目录下，里面存放了该Slave 的Master 端的
相关信息，包括Master 的主机地址，连接用户，连接密码，连接端口，当前日志位置，已
经读取到的日志位置等信息。
2、relay log 和relay log index
mysql-relay-bin.xxxxxn 文件用于存放Slave 端的I/O 线程从Master 端所读取到
的Binary Log 信息，然后由Slave 端的SQL 线程从该relay log 中读取并解析相应的
日志信息，转化成Master 所执行的SQL 语句，然后在Slave 端应用。
mysql-relay-bin.index 文件的功能类似于mysql-bin.index ，同样是记录日志的存
放位置的绝对路径，只不过他所记录的不是Binary Log，而是Relay Log。
3、relay-log.info 文件：
类似于master.info，它存放通过Slave 的I/O 线程写入到本地的relay log 的相关信
息。供Slave 端的SQL 线程以及某些管理操作随时能够获取当前复制的相关信息。
2.1.4 其他文件：
1、system config file
MySQL 的系统配置文件一般都是“my.cnf”，Unix/Linux 下默认存放在"/etc"目录下，
Windows 环境一般存放在“c:/windows”目录下面。“my.cnf”文件中包含多种参数选项组
（group），每一种参数组都通过中括号给定了固定的组名，如“[mysqld]”组中包括了mysqld
服务启动时候的初始化参数，“[client]”组中包含着客户端工具程序可以读取的参数，此
外还有其他针对于各个客户端软件的特定参数组，如mysql 程序使用的“[mysql]”，mysqlchk
使用的“[mysqlchk]”，等等。如果读者朋友自己编写了某个客户端程序，也可以自己设定
一个参数组名，将相关参数配置在里面，然后调用mysql 客户端api 程序中的参数读取api
读取相关参数。
2、pid file
pid file 是mysqld 应用程序在Unix/Linux 环境下的一个进程文件，和许多其他
Unix/Linux 服务端程序一样，存放着自己的进程id。
3、socket file
socket 文件也是在Unix/Linux 环境下才有的，用户在Unix/Linux 环境下客户端连接
可以不通过TCP/IP 网络而直接使用 Unix Socket 来连接MySQL。
分表:
垂直分表
将部分字段分离出来，设计成分表，根据主表的主键关联
水平分表
将相同字段表中的记录按照某种Hash算法进行拆分多个分表
mysql分区技术（必须5.1版以上），与水平分表有点类似，但是它是在逻辑层进行的水平分表
Query Cache优化
通过执行如下命令获得MySQL 中Query Cache 相关的系统参数变量：
show variables like '%query_cache%';
参数如下：
have_query_cache：该MySQL 是否支持Query Cache；
query_cache_limit：Query Cache 存放的单条Query 最大Result Set ，默认1M；
query_cache_min_res_unit：Query Cache 每个Result Set 存放的最小内存大小，默认4k；
query_cache_size：系统中用于Query Cache 内存的大小；
query_cache_type：系统是否打开了Query Cache 功能；
query_cache_wlock_invalidate：针对于MyISAM 存储引擎，设置当有WRITE LOCK 在某个
Table 上面的时候，读请求是要等待WRITE LOCK 释放资源之后再查询还是允许直接从Query
Cache 中读取结果，默认为FALSE（可以直接从Query Cache 中取得结果）。
以上参数的设置主要是“query_cache_limit”和“query_cache_min_res_unit”两个参数的设置需
要做一些针对于应用的相关调整。如果我们需要Cache 的Result Set 一般都很小（小于4k）的话，可
以适当将“ query_cache_min_res_unit ” 参数再调小一些， 避免造成内存的浪费，
“query_cache_limit”参数则不用调整。而如果我们需要Cache 的Result Set 大部分都大于4k 的话，
则最好将“query_cache_min_res_unit”调整到和Result Set 大小差不多，“query_cache_limit”的
参数也应大于Result Set 的大小。当然，可能有些时候我们比较难准确的估算Result Set 的大小，
那么当Result Set 较大的时候，我们也并不是非得将“query_cache_min_res_unit”设置的和每个
Result Set 差不多大，是每个结果集的一半或者四分之一大小都可以，要想非常完美的完全不浪费任何
内存确实也是不可能做到的。
如果我们要了解Query Cache 的使用情况，则可以通过Query Cache 相关的状态变量来获取，
通过如下命令：
show status like 'Qcache%';
结果参数如下：
Qcache_free_blocks：Query Cache 中目前还有多少剩余的blocks。如果该值显示较大，
则说明Query Cache 中的内存碎片较多了，可能需要寻找合适的机会进行整理。
Qcache_free_memory：Query Cache 中目前剩余的内存大小。通过这个参数我们可以较为准
确的观察出当前系统中的Query Cache 内存大小是否足够，是需要增加还是过多了；
Qcache_hits：多少次命中。通过这个参数我们可以查看到Query Cache 的基本效果；
Qcache_inserts：多少次未命中然后插入。通过“Qcache_hits”和“Qcache_inserts”两
个参数我们就可以算出Query Cache 的命中率了：
Query Cache 命中率= Qcache_hits / ( Qcache_hits + Qcache_inserts )；
Qcache_lowmem_prunes：多少条Query 因为内存不足而被清除出Query Cache。通过
Qcache_lowmem_prunes和Qcache_free_memory相互结合，能够更清楚的了解到我们系
统中Query Cache 的内存大小是否真的足够，是否非常频繁的出现因为内存不足
而有Query 被换出
Qcache_not_cached：因为query_cache_type 的设置或者不能被cache 的Query 的数量；
Qcache_queries_in_cache：当前Query Cache 中cache 的Query 数量；
Qcache_total_blocks：当前Query Cache 中的block 数量；
mysql常用别的优化：
max_connections:整个MySQL 允许的最大连接数；
这个参数主要影响的是整个MySQL 应用的并发处理能力，当系统中实际需要的连接量大于
max_conecctions 的情况下，由于MySQL 的设置限制，那么应用中必然会产生连接请求的等待，
从而限制了相应的并发量。所以一般来说，只要MySQL 主机性能允许，都是将该参数设置的尽
可能大一点。一般来说500 到800 左右是一个比较合适的参考值
max_user_connections:每个用户允许的最大连接数；
上面的参数是限制了整个MySQL 的连接数，而max_user_connections 则是针对于单个用户的连
接限制。在一般情况下我们可能都较少使用这个限制，只有在一些专门提供MySQL 数据存储服
务，或者是提供虚拟主机服务的应用中可能需要用到。除了限制的对象区别之外，其他方面和
max_connections 一样。这个参数的设置完全依赖于应用程序的连接用户数，对于普通的应用来
说，完全没有做太多的限制，可以尽量放开一些。
net_buffer_length:网络包传输中，传输消息之前的net buffer 初始化大小；
这个参数主要可能影响的是网络传输的效率，由于该参数所设置的只是消息缓冲区的初始化大
小，所以造成的影响主要是当我们的每次消息都很大的时候MySQL 总是需要多次申请扩展该缓
冲区大小。系统默认大小为16KB，一般来说可以满足大多数场景，当然如果我们的查询都是非
常小，每次网络传输量都很少，而且系统内存又比较紧缺的情况下，也可以适当将该值降低到
8KB。
max_allowed_packet:在网络传输中，一次传消息输量的最大值；
这个参数与net_buffer_length 相对应，只不过是net buffer 的最大值。当我们的消息传输量
大于net_buffer_length 的设置时，MySQL 会自动增大net buffer 的大小，直到缓冲区大小达
到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 中，为了尽可提高客户端请求创建连接这个过程的性能，实现了一个Thread Cache 池，将
空闲的连接线程存放在其中，而不是完成请求后就销毁。这样，当有新的连接请求的时候，MySQL 首先会
检查Thread Cache 池中是否存在空闲连接线程，如果存在则取出来直接使用，如果没有空闲连接线程，
才创建新的连接线程。在MySQL 中与连接线程相关的系统参数及状态变量说明如下：
thread_cache_size:Thread Cache 池中应该存放的连接线程数。
当系统最初启动的时候，并不会马上就创建thread_cache_size 所设置数目的连接线程存放在
Thread Cache 池中，而是随着连接线程的创建及使用，慢慢的将用完的连接线程存入其中。当
存放的连接线程达到thread_cache_size 值之后，MySQL 就不会再续保存用完的连接线程了。
如果我们的应用程序使用的短连接，Thread Cache 池的功效是最明显的。因为在短连接的数据
库应用中，数据库连接的创建和销毁是非常频繁的，如果每次都需要让MySQL 新建和销毁相应
的连接线程，那么这个资源消耗实际上是非常大的，而当我们使用了Thread Cache 之后，由于
连接线程大部分都是在创建好了等待取用的状态，既不需要每次都重新创建，又不需要在使用
完之后销毁， 所以可以节省下大量的系统资源。所以在短连接的应用系统中，
thread_cache_size 的值应该设置的相对大一些，不应该小于应用系统对数据库的实际并发请求
数。而如果我们使用的是长连接的时候，Thread Cache 的功效可能并没有使用短连接那样的大，但
也并不是完全没有价值。因为应用程序即使是使用了长连接，也很难保证他们所管理的所有连
接都能处于很稳定的状态，仍然会有不少连接关闭和新建的操作出现。在有些并发量较高，应
用服务器数量较大的系统中，每分钟十來次的连接创建与关闭的操作是很常见的。而且如果应
用服务器的连接池管理不是太好，容易产生连接池抖动的话，所产生的连接创建和销毁操作将
会更多。所以即使是在使用长连接的应用环境中，Thread Cache 机制的利用仍然是对性能大有
帮助的。只不过在长连接的环境中我们不需要将thread_cache_size 参数设置太大，一般来说
可能50 到100 之间应该就可以了。
thread_stack:每个连接线程被创建的时候，MySQL 给他分配的内存大小。
当MySQL 创建一个新的连接线程的时候，是需要给他分配一定大小的内存堆栈空间，以便存放
客户端的请求Query 以及自身的各种状态和处理信息。不过一般来说如果不是对MySQL 的连接线
程处理机制十分熟悉的话，不应该轻易调整该参数的大小，使用系统的默认值（192KB）基本上
可以所有的普通应用环境。如果该值设置太小，会影响MySQL 连接线程能够处理客户端请求的
Query 内容的大小，以及用户创建的Procedures 和Functions 等。
连接线程相关的系统变量：
show variables like 'thread%';
系统被连接的次数以及当前系统中连接线程的状态值：
show status like 'connections';
show status like '%thread%';
部分参数分析如下：
Connections:共接收到客户端的连接次数
Threads_created:共创建了连接线程数
Threads_connected: 连接线程处于和客户端连接的状态数目
Threads_running:处于活动状态的连接数
Threads_cached:线程缓存池中缓存的连接线程数
整合读写分离的方法：
1.自行开发中间代理层
2.利用mysql proxy等第三方工具，如360,alibaba提供的
利用分布式并行计算实现大数据量的高性能运算
常用的第三方中间件有：
Google 的 MapReduce
Yahoo 的 Hadoop