1.mysql有许多系统变量，可以设置，系统变量设置不同，不同的系统将导致执行状态。
故mysql提供两组命令，分别查看系统设置和执行状态。
1、系统设置：
SHOW [GLOBAL | SESSION] VARIABLES [like_or_where]
SHOW VARIABLES shows the values of MySQL system variables.
2、执行状态：
SHOW [GLOBAL | SESSION] STATUS [like_or_where]
SHOW STATUS provides server status information.
备注：SHOW XXX 可能会显示非常多内容。类似Linux下内容太多了，往往须要grep来过滤，那么mysql也考虑到了这点，使用LIKE字句能够过滤。
在安装完MySQL之后。肯定是须要对MySQL的各种參数选项进行一些优化调整的。
尽管MySQL系统的伸缩性非常强，既能够在有非常充足的硬件资源环境下高效的执行，也能够在极少资源环境下非常好的执行。但无论如何，尽可能充足的硬件资源对MySQL的性能提升总是有帮助的。在这一节我们主要分析一下MySQL的日志（主要是Binlog）对系统性能的影响。并依据日志的相关特性得出对应的优化思路。
日志产生的性能影响
因为日志的记录带来的直接性能损耗就是数据库系统中最为昂贵的IO资源。
在之前介绍MySQL物理架构的章节中，我们已经了解到了MySQL的日志包含错误日志（ErrorLog），更新日志（UpdateLog）。二进制日志（Binlog）。查询日志（QueryLog），慢查询日志（SlowQueryLog）等。当然。更新日志是老版本号的MySQL才有的。眼下已经被二进制日志替代。
在默认情况下，系统只打开错误日志。关闭了其它全部日志，以达到尽可能降低IO损耗提高系统性能的目的。可是在一般略微重要一点的实际应用场景中，都至少须要打开二进制日志。由于这是MySQL非常多存储引擎进行增量备份的基础，也是MySQL实现复制的基本条件。有时候为了进一步的性能优化，定位运行较慢的SQL语句。非常多系统也会打开慢查询日志来记录运行时间超过特定数值（由我们自行设置）的SQL语句。
普通情况下，在生产系统中非常少有系统会打开查询日志。由于查询日志打开之后会将MySQL中运行的每一条Query都记录到日志中，会该系统带来比較大的IO负担，而带来的实际效益却并非非常大。一般仅仅有在开发測试环境中，为了定位某些功能详细使用了哪些SQL语句的时候，才会在短时间段内打开该日志来做对应的分析。所以，在MySQL系统中。会对性能产生影响的MySQL日志（不包含各存储引擎自己的日志）主要就是Binlog了。
2.Binlog 相关參数及优化策略。
binlog_cache_size
Binlog_cache_disk_use
Binlog_cache_use
max_binlog_cache_size
max_binlog_size
sync_binlog
“binlog_cache_size"：在事务过程中容纳二进制日志SQL语句的缓存大小。
二进制日志缓存是server支持事务存储引擎而且server启用了二进制日志(—log-bin选项)的前提下为每一个client分配的内存，注意，是每一个Client都能够分配设置大小的binlogcache空间。假设读者朋友的系统中常常会出现多语句事务的华，能够尝试添加该值的大小，以获得更有的性能。
当然，我们能够通过MySQL的下面两个状态变量来推断当前的binlog_cache_size的状况：Binlog_cache_use和Binlog_cache_disk_use。
Binlog_cache_disk_use:表示由于我们binlog_cache_size设计的内存不足导致缓存二进制日志用到了暂时文件的次数
Binlog_cache_use :表示 用binlog_cache_size缓存的次数
当相应的Binlog_cache_disk_use 值比較大的时候 我们能够考虑适当的调高 binlog_cache_size 相应的值
show global status like ‘bin%‘;
上述语句我们能够得到当前 数据库binlog_cache_size的使用情况
mysql> show status like ‘binlog_%‘;
+-----------------------+-----------+
| Variable_name |
Value |
+-----------------------+-----------+
| Binlog_cache_disk_use | 0 |
| Binlog_cache_use |
120402264 |
+-----------------------+-----------+
“max_binlog_cache_size”：和"binlog_cache_size"相相应，可是所代表的是binlog可以使用的最大cache内存大小。
当我们运行多语句事务的时候。max_binlog_cache_size假设不够大的话，系统可能会报出“Multi-statementtransactionrequiredmorethan‘max_binlog_cache_size‘bytesofstorage”的错误。
“max_binlog_size”：Binlog日志最大值，一般来说设置为512M或者1G，但不能超过1G。
该大小并不能很严格控制Binlog大小。尤其是当到达Binlog比較靠近尾部而又遇到一个较大事务的时候。系统为了保证事务的完整性。不可能做切换日志的动作，仅仅能将该事务的全部SQL都记录进入当前日志，直到该事务结束。这一点和Oracle的Redo日志有点不一样，由于Oracle的Redo日志所记录的是数据文件的物理位置的变化，并且里面同一时候记录了Redo和Undo相关的信息，所以同一个事务是否在一个日志中对Oracle来说并不关键。
而MySQL在Binlog中所记录的是数据库逻辑变化信息，MySQL称之为Event。实际上就是带来数据库变化的DML之类的Query语句。
“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时报或其他许多。
版权声明：本文博主原创文章，博客，未经同意不得转载。