月度归档： 2017年6月

在短连接的应用Thread_Cache的功效非常明显，因为在应用中数据库的连接和创建是非常频繁的，如果不使用Thread_Cache那么消耗的资源是非常可观的！

在长连接中虽然带来的改善没有短连接的那么明显，但是好处是显而易见的。

当一个连接处理完之后 不是立即销毁 而是把连接cache住

当有新连接连接时 用cache住的连接来处理

主要用来处理短连接请求

MySQL 企业版开始支持thread pool， MariaDB和Percona也免费支持

当连接数满了 管理员都连不上去 这个时候可以用extra_port功能

用这个端口进行处理一些事情

日常使用和监控还是继续使用正常的业务端口，但管理员救急时用extra_port连接mysqld 把连接释放出来

需要有对应的授权才可以

一般管理员都是本地管理 （root@localhost）

因为extra_port是个额外的端口不能采用socket的方式连接进去

只能使用TCP的方式连接

那么这个时候就需要新增一个授权(root@本机IP)

Thread Cache命中率： Thread_Cache_Hit=(Connections-Thread_created)/Connections*100%

binlog_cache_size 默认值是32k 一般设置成1,2M就够了 一般sql也没这么大

在事务过程中容纳二进制日志SQL 语句的缓存大小

二进制日志缓存是服务器支持事物存储引擎并且服务器启用了二进制日志（–log-bin选项）的前提下为没个客户端分配的内存

如果系统中经常会出现多语句事务的话，可以尝试增加该值的大小，以获得更好的性能

事物表 在事物没有结束之前 需要把数据放在cache里面 然后整个事物完成之后 

我们再把整个事物相关的sql文件写会文件 这些sql我们就把他放在binlog_cache里面

主要是给事物引擎产生的sql 作为cache 提高sql写入的效率

当然，我们可以通过MySQL的一下两个状态变量来判断当前的binlog_cache_size的状况：Binlog_cache_use和Binlog_cache_disk_use

binlog hit ratio = (Binlog_cache_use)/(Binlog_cache_use + Binlog_cache_disk_use)

当然我们执行多语句事务的时候，max_binlog_cache_size 如果不够大的话，系统可能会报出“Multi-statement transaction required more than 'max_binlog_cache_size' bytes ofstorage”的错误

比如，我们开启binlog时，执行load data infile，将一个大文件导入时可能会出现这个错误提示 需要注意一下

临时执行大文件的话我们可以这样

set sql_log_bin=0;

load data infile…

然后再slave 再次执行load data

一般大数据批量导入的时候（维护的时候，不是工作时间） 是把binlog关掉然后再master上导一下 在slave上导一下

tmp_table_size 是MySql的临时表缓冲大小

大多数临时表是基于内存的（HEAP）表

但是，具有大的记录长度的临时表（所有列的长度的和）或包含BLOB列的表存储在硬盘上

如果某个内部heap（堆积）表大小超过tmp_table_size， MySQL可以根据需要自动将内存中的heap表改为基于硬盘的MyISAM表

如果执行计划中显示有Using temporary，那么就意味着会用到临时表了